ASADAL/SIM : A Simulation-based Methodology for Behavioral Analysis and Validation of Real-Time Software Speci cation Kyo C. Kang, Kwan W. Lee, Ji Y. Lee and Gerard J. Kim Department of Computer Science and Engineering Pohang University of Science and Technology, Pohang Kyungbuk 790-600, Korea
[email protected] tel: (82)562-279-2719 fax: (82)562-279-2299
Abstract
Despite considerable advancements in software engineering method during the past three decades, requirement engineering of large and complex software systems still remains to be one of the more dicult and active research problems. One such diculty is in developing correct and useful methods for analysis and validation of real-time software speci cations. Formal methods have been applied in an attempt to analyze real-time properties of software speci cations, however, users have dicult time in comprehending formal speci cations and visualizing the nal system behavior. In addition, because of its computational complexity, formal methods may not be a practical for even systems of moderate size and complexity. On the other hand, simulation is one e ective method for verifying various characteristics of real-time systems and validating user requirements during early software development stages. Although not as complete as the formal approaches, simulation may provide a rough picture of the nal system behavior. This paper introduces a simulation-based behavioral analysis and validation method (and a tool) for real-time software speci cations called ASADAL/SIM. It is a subsystem of a larger computer-aided real-time software development environment called ASADAL developed at POSTECH [13]. First, requirements are speci ed by software developers using various formal languages. Simulation primitives are then added to these speci cations in order to assign stochastic behaviors to external entities and internal processes, and to build a simulation model. ASADAL/SIM executes the model and, at the same time, provides a \look and feel" of the nal system behavior by graphically showing the internal workings of the system and presenting various analytical results and system statistics. An elevator control system is used throughout the paper to illustrate the method.
Keywords: Real-time systems, Validation, Requirement Analysis, Software Speci cation, Statechart, Simulation
1
Customer Domain Expert User
Verification
Elicitation
Formal Analysis
Viewpoint analysis Scenario Generation
Validation Simulation Analysis Prototyping
Unclear Requirements
Critical Requirements
Verified & Validated Requirements
Figure 1: Requirements Engineering Activities
1 Introduction Despite considerable advancements in software engineering method during the past three decades, requirement engineering of large and complex software systems remains as one of the more dicult and active research problems. A complete, correct, and practical analysis and validation of real-time software in early stages of development is a very dicult task. The rst diculty with requirement engineering arises from the inevitable reality that requirements are often given by customers who do not know much about computers, and by computer programmers who, in turn, do not know much about the application domain, and thus producing a potentially con icting, inconsistent, and even infeasible speci cations. In addition, requirement speci cations tend to be informal, vague, ambiguous and incomplete, and therefore dicult to analyze or validate. Various formal methods have been applied in an attempt to analyze real-time properties of software speci cations [2][12][16][17]. However, with these methods users have dicult time in comprehending formal speci cations and visualizing the nal system behavior. In addition, because of its computational complexity, formal methods may not be practical for systems of moderate size and complexity. Consequently, vicious cycles of design iterations often occur due to insucient validation. For example, Davis has reported that requirement errors found during implementation can cost over ve to ten times the cost of xing them during the requirement phase [3]. To handle the aforementioned diculties in requirement engineering, a general multidisciplinary development paradigm has been proposed by Kang et al. [14] that includes stages of elicitation, veri cation and validation as shown in Figure 1. The customer, user, domain expert, and analyst all participate in every stages of the software development. Requirements are rst elicited from the customer, users, and domain experts. These
2
user requirements generally include speci cations of external behaviors of the system speci ed in terms of inputs to the system and outputs generated by the system (in response to the user inputs). Based on these requirements, the analyst speci es what needs to be done internally, i.e., internal speci cations are made. Of these requirements, unclear ones should be validated and critical ones must be veri ed before the further development starts. Typically, formal methods and simulations are used to verify and validate requirements. Validation refers to a process of clarifying and unambiguating user needs, and veri cation refers to a process of \proving" if certain user speci ed properties will be satis ed. Formal methods are used to guarantee correctness of critical properties. With formal methods, requirements are speci ed using mathematical constructs, and system properties such as safety ([12], [16]), liveness, consistency and completeness [10] are proved mathematically. For even a moderately sized and complex systems, however, computational complexity of formal methods are enormous, and thus, may not be practical in general. Therefore, formal methods are used for verifying a few very critical properties of a given system. Simulation, on the other hand, has emerged as an alternative and practical method for validating user requirements by, for example, graphically animating system behavior and presenting useful feedback to the user. Simulation can provide a projected \look and feel" of the system behavior (for a given scenario) and induce quick feedback from users before more detailed design and implementation can start. Compared to the formal methods, the requirement engineering process is more ecient because the design cycle between elicitation and validation is shorter, and more alternatives may be explored. Speci cation execution methods have their own weaknesses too, however. They are generally used to increase the level of con dence about the speci cation, and cannot \guarantee" the correctness of speci cations. In order to guarantee certain properties of the system they must be tested under all possible cases, which is almost impossible for systems of any reasonable size. Therefore, we believe that a method that mixes both methods is necessary and appropriate for e ective requirement analysis. ASADAL (A System Analysis and Design Aid tooL system), developed at POSTECH, is one such method (and an environment) that uses and integrates both formal and simulation based approaches to requirement engineering [13]. ASADAL, shown in Figure 2, of which ASADAL/SIM is a subsystem, is composed of the following modules. ASADAL/SPEC: a front end for system speci cation using Message Sequence Diagrams (MSD), Time Enriched Statecharts (TES) and Data Flow Diagrams (DFD). ASADAL/PROVER: a temporal logic based proof system for veri cation of critical system properties such as safety, liveness, and responsiveness. ASADAL/SIM: a discrete event simulator and analyzer for validation of real-time software. ASADAL/PROTO: an environment and artifact prototyping and simulation module (in development). ASADAL/ARCH: a detailed design (e.g. skeletal code generation) module based on software reuse and reference architecture concept (planned for development). In this paper, we focus on the ASADAL/SIM, the speci cation simulator and analyzer. For a more detailed description of ASADAL, refer to [13]. Some of the distinguishing features of ASADAL/SIM are that it: allows real-value computations, contrast to, for instance, simple queuing models, and thus, more detailed and realistic simulation results are obtained, provides both dynamic and static data analysis and viewers for on-line monitoring and o -line analysis of system behavior and performance, and
3
ASADAL/SPEC - Message Sequence Diagrams - Data Flow Diagrams - Time-Enriched Statecharts
ASADAL/PROVER - Verification of Real-Time Constraints - Use of Real-Time Temporal Logic
ASADAL/SIM - Simulation of System Specification - Data Analysis
ASADAL/PROTO (still in development) - External Object Modeling - Artifact Design - Artifact Simulation
ASADAL/ARCH (planned for development) - Reference Architectures - Software Library - Skeletal Design
Figure 2: Architecture of ASADAL. visualizes interactions between the target system and external objects through animations. We believe that providing the capability of actually \seeing" how external objects behave and interact with the target system, in addition to quantitative analysis, is an essential feature for validating real-time embedded systems in early design stages. Currently, ASADAL/SIM only models the \software" part of the larger embedded system, and to be complete, ASADAL/PROTO is in development to provide a capability to also model exact behaviors of external objects, de ne the \artifact" part (e.g. actual geometric shapes) of the embedded system, and thus provide a total prototyping environment for embedded systems. This paper is organized as the following. In Section 2, we rst brie y describe previous related work and compare them to our approach. An overview of ASADAL/SIM method is presented in Section 3. Section 4 describes the three step requirement analysis and validation method of ASADAL/SIM: namely, building a simulation model, executing the model, and analyzing the results for further design re nements. Finally in Section 5, we summarize and discuss the merits and shortcomings of the proposed method and present currently planned future work.
2 Related Work There have been several other e orts to implement speci cation simulation for user requirement validation. Balzer et al. [1] has proposed an operational speci cation language, called Gist [4], used for validating speci cation through speci cation execution. However, Balzer's system does not provide visual presentation of the speci cation execution and the language is not suitable for expressing real-time constraints1. Gaskell and Phillips [7] developed a CASE environment, called EGS (Executable Graphical Speci cation), that uses DeMarco's DFD notation for describing functional models. User augments the model with code elements. This enables the models to be executed in an interpretive manner, thus allowing the functionality of the system to be observed. However, EGS is designed for data-driven systems and executes the models in an interactive mode only, which is not appropriate for executing and analyzing speci cations of large and complex real-time systems. Coomber [6] developed a CASE environment, named SCHEMASIM, for modeling realtime systems and simulating their behaviors. SCHEMASIM uses a Data Flow Diagram extended for real-time systems speci cation purposes [18], [5]. It can describe functional components of a system in terms of data and control signal ow, control mechanisms (that control the execution of the functional components), and required timing constraints. 1
The target design domain of ASADAL is real-time embedded systems.
4
Specification (ASADAL/SPEC)
Simulation Model Construction
Model Execution
Data Analysis
Figure 3: Process Activities of ASADAL/SIM Operations of primitive and external functions are speci ed using the Component Description Language (CDL). SCHEMASIM has facilities for interactively executing the speci ed models and graphically displaying its execution. A desirable feature would be a batch mode simulation for testing large and complex systems. Harel [8] developed a graphical CASE environment, called STATEMATE, for speci cation, analysis, design, and documentation of large and complex reactive systems. For analysis of complex real-time systems, STATEMATE has more comprehensive features such as batch mode simulation, a set of testing procedures (for reachability, nondeterminism, and deadlock), three di erent speci cation methods to support multiple views, and easy-to-understand semantics. ASADAL has been in uenced by work of STATEMATE. ASADAL has the following distinctive features (as implemented in ASADAL/SPEC and ASADAL/SIM). First, a new special purpose speci cation construct, called the Message Sequence Diagram (MSD), has been added, that is designed to capture requirements of the target system with respect to its external entities (i.e. the speci cation process with MSD occurs only at the outermost system boundary). Although STATEMATE provides three di erent methods of specifying relationships among di erent subentities of the system, they all lack capabilities in masking out system internals from externally observable system behaviors. MSD is particularly useful because the customer is one of the main external entities of the system to be designed. Therefore, using MSD, one can easily capture system requirements, for example, from a customer's point of view, treating the target system as a black box. In fact, the customer here may be replaced by any external entity, and thus, speci cations centered around that external entity can be easily constructed likewise. This can also be very useful for system engineers whose mission is to integrate the target system to other external entities. Secondly, in ASADAL/SIM, speci cation execution can be performed without completely specifying the requirements. A gross level simulation may be performed by assigning rough processing speci cations (e.g. processing time) to abstract processes that are yet to be decomposed or re ned. And nally, ASADAL/SIM o ers a richer set of analysis options, such as data queue length, process service time, process waiting time, other state statistics, etc. in addition to the three tests available in STATEMATE.
3 An Overview of ASADAL/SIM The major activities of ASADAL/SIM are: Model Construction, Model Execution, and Data Analysis. As shown in Figure 3, before constructing a simulation model, requirements are rst speci ed using the ASADAL/SPEC. ASADAL/SPEC provides a systematic method for capturing both user requirements and internal system speci cations. As brie y explained in Section 2, user requirements are speci ed in terms of interaction scenarios using the MSD and then, based on these user requirements, internal system models are speci ed using the TES (Time-Enriched Statechart) and DFD (Data Flow Diagram) [13].
5
Building a simulation model requires users to provide simulation related information such as approximate process computation time, a rough description of the computation itself, stochastic behavior of external inputs (e.g. data arrival rate), and breakpoints for exerimenting with the system during simulation. A simple script-like language called the Simulation Description Language (SDL) is used for this purpose. The simulation model is then interpreted and executed accordingly in an interactive or non-interactive manner. While in execution, various types of useful information, such as state transition and statistical data, are visually presented to the user for a quick manual inspection and analysis. Interactive simulation is useful when an analyst wants to explore the system behavior step by step. Users are responsible for generating control signals or data out of external entities. Users can also change system states interactively to situate special conditions and to debug and locate a cause of an unexpected behavior. Non-interactive (batch) simulation is useful for describing a non-scenario based (e.g. random external behavior) execution with a large amount of input/output data or to simulate stochastic behaviors of real-time systems. In a non-interactive simulation, ASADAL/SIM's simulation driver is responsible for simulating the behaviors of external entities, but users may also take part in the simulation interactively to handle speci c situations. Data gathered during the simulation are examined manually or using other methods such as the stochastic analysis and the input/output analysis [11]. Since speci cation execution may not proceed in strict real-time, models may be replayed and animated in real time later based on data logs gathered during initial speci cation execution run. Feedback for software respeci cation may be obtained during this stage or even during the speci cation execution stage during which users can visually check the system behavior. The above activities are repeated until requirements are speci ed, analyzed, and validated completely.
4 ASADAL/SIM In this section, we describes the three step requirement analysis and validation method of ASADAL/SIM: namely, building a simulation model, executing the model, and analyzing the results for further design re nements.
4.1 Simulation Model
The simulation model of ASADAL/SIM comprises of four components: an external and internal viewpoint speci cation speci ed using ASADAL/SPEC's three methods (namely, MSD, TES and DFD), process speci cation information, and a simulation driver program as shown in Figure 4. External viewpoint speci cations refers to user requirements speci ed using the MSD and represents various scenarios of the external behavior of a real-time system in terms of a sequence of data or control signals owing between the target system and external entities [13]. Based on number of external views speci ed with MSD, an internal view of the system is speci ed and re ned using the DFD and TES as shown in the same gure. The DFD and TES diagrams represent functional and behavioral aspects of the system, respectively. Processes at the lowest level in the DFD hierarchy are called the primitive processes and their processing time and computations are speci ed using the Simulation Description Language (SDL) in order to carry out the simulation. The simulation driver program represents behaviors of external entities and is used to drive the simulation. The program exists in a form of a script (called the Simulation
6
Figure 4: ASADAL Simulation Model Control Language (SCL)) and when driving a simulation according to the scenario speci ed in the external viewpoint speci cation, it is constructed automatically based on it. Users may alternatively write a simulation driver program using the SCL to specify an external behavior that does not follow a strict scenario, for example, by simply assigning stochastic behavior for events and input data without speci c ordering among them (e.g. queueing simulation, Monte Carlo simulation, etc.). In the following sections, each of these model components is discussed in further details and illustrated using an Elevator Control System (ECS) design.
4.1.1 External and Internal Viewpoint Speci cation
Figure 5 is an MSD representing a sequence of events owing among various Elevator System components including the Elevator Control System. Real-time requirements speci ed in terms of timing constraints between a stimulus event and its response event are speci ed using three constructs, namely, MaxDist(t) MinDist(t), and JustDist(t) (See the ovals in Figure 5.), each denoting the maximum allowed time interval, the minimum allowed time interval, and the exact time interval that must be satis ed respectively. These time requirements can be validated during simulation later. Functional decompositions of the system is represented and carried out using the DFD as shown in Figure 4. The DFD is similar to the Activity-Chart of STATEMATE except that the DFD provides an additional \port" connector to improve traceability of information ow between diagrams [13]. Functions carried out by the system are represented by processes in the DFD, and may be decomposed into lower level DFDs. Processes in the lowest level diagram in the DFD hierarchy are called the primitive processes. Figure 6 shows a DFD re ned from the `Elevator Control System' entity in Figure 5. Rectilinear shapes stand for processes, or functions. Each process receives data or control signals as input and generates data or control signals as output. Nonprimitive processes in this diagram are decomposed into lower level DFDs. The DFD de nes only the functionality, of a system in terms of processes. The execution order of processes is speci ed using TES. TES is combined with each DFD and controls the processes in the DFD. Processes speci ed in a DFD are allocated to states
7
Door
ECS
Cage
User
CageState=IDLE, DoorState=CLOSED elevatorCall(fl,dir) up
[Floor
