Method and system for generating stateflow models from software requirements

[0001] This application claims the benefit of Patent Application No. 1330/CHE/2014, filed in India on Mar. 13, 2014.

[0002] The field generally relates to software engineering, and more particularly, to a method and system for generating stateflow models from software requirements.

[0003] Generally, due to increasing complexity and heterogeneity of software, it requires significant emphasis on evolving further requirements based software testing. Existing techniques in the area of requirement based software testing focuses on formalizing the software requirements as linear temporal logic properties and then generating test cases from the requirement model (herein after referred as stateflow model) that satisfy a coverage goal over the linear temporal logic properties. However, the current practice in industries is the manual extraction of stateflow model and properties from the software requirements.

[0004] The manual extraction of stateflow model from the software requirements has significant limitations. Firstly, this process incurs additional overhead both in terms of cost and time in generating the stateflow models from the requirements and thereby delays the overall software test case generation process. This in turn significantly impact on the software and product development and delivery process of the organization. Secondly, the manually generated software model may be error-prone or may not represent some functionality, as a result the model might not be able to uncover some critical bugs (such as, missing condition, variable, reference, operator negation, calibration mismatch, etc.) in the software when it is used to generate test cases. Moreover, even if there is any bug detected in the software it might be impossible to map the bug to the requirement. Therefore, there is a need to automatically generate executable stateflow models from the software requirements which will in turn facilitate timely generation of adequate and optimal test cases

[0005] Hence, there is a need of a method and system for generating stateflow models from software requirements to address the aforementioned issues.

[0006] An object of the invention is to provide a method and system for generating stateflow models from software requirements. This provides an automated technique to the engineering community for deriving formal stateflow model from the software requirements which will facilitate in generating adequate and quality test cases for validating the software or guidelines for changes in the requirements.

[0007] As described herein, a variety of other features and advantages can be into the technologies as desired.

[0008] The foregoing and other features and advantages will become more apparent to one skilled in the art from the following detailed description of disclosed embodiments, which proceeds with reference to the accompanying drawings.

[0013] The technologies described herein can be used for automated generation of stateflow models from software requirements. Adoption of the technologies can provide an efficient technique for reducing test effort and associated cost required in software development.

[0014] The technologies are targeted to significantly save the effort (both in terms of cost and time) of generating test cases from the software requirements. It will also increase the scope of detecting more potential bugs in the software. This could provide the development team more time to fix the reported bugs due to decrease in time taken for manual bug detection and reporting. And, clients greatly benefit from the technologies because they enjoy accurate and credible delivery of services to their specific business needs and reach market faster as it reduces testing effort.

[0015] FIG. 1 is a flowchart of an exemplary method 100 of implementing the generation of stateflow models from software requirements described herein and can be implemented for example in a system such as shown in FIG. 2. The technologies described herein can be generic to the specifics of operating systems or hardware and can be applied in any variety of environments to take advantage of the described features.

[0016] At 110, software requirements for a new software to be developed are received as input. The software requirements may include procedural statement, configuration parameters and requirement criteria such as functional coverage. Such requirements can be provided by a user or another software tool.

[0017] At 120, the received software requirements are annotated to create annotated software requirements. The step of annotating may include labelling each of the procedural statement received as software requirements. The step of annotating may further include storing the labelled procedural statement with the definition and scope of the configuration parameters as parameter definition file to create annotated software requirements.

[0018] At 130, the annotated software requirements are parsed to generate a plurality of stateflow blocks. The step of parsing may include creating a plurality of stateflow blocks for the operators of the labeled procedural statement from the parameter definition file. The step of parsing may further include mapping the definition and scope of the configuration parameters from the parameter definition file to the created stateflow blocks.

[0019] At 140, the created stateflow blocks are connected to generate a stateflow model. The step of connecting may include identifying, for each pair of stateflow blocks the common parameter with scope. The step of connecting may further include interconnecting, the software blocks, based on the identified common parameter to generate the stateflow model till no further interconnection is possible.

[0020] The method 100 may also include validating the generated stateflow model by simulation run of test data. The method 100 may further include displaying the generated stateflow model.

[0021] The method 100 and any of the methods described herein can be performed by computer-executable instructions stored in one or more computer-readable media (storage or other tangible media) or stored in one or more compute readable storage devices.

[0022] FIG. 2 is a block diagram of an exemplary system 200 implementing the generation of stateflow model from software requirements described herein. In the example, one or more computers in a computing environment implement system 200 that accepts as input software requirements 210. The system 200 includes system logic 220, which processes software requirements 210 to provide stateflow model 230. The input software requirements 210 may include procedural statement, configuration parameters and requirement criteria such as functional coverage. Such requirements can be provided by a user or another software tool. The system logic 220 annotates 222 the received software requirements to create annotated software requirements. The annotating 222 by system logic 220 may include labelling each of the procedural statement received as software requirements. The annotating 222 by system logic 220 may also include storing the labelled procedural statement with the definition and scope of the configuration parameters as parameter definition file to create annotated software requirements. The system logic 220 also parse 224 the annotated software requirements to create a plurality of stateflow blocks. The parsing 224 may include creating a plurality of stateflow blocks for the operators of the labeled procedural statement from the parameter definition file. The parsing 224 may further include mapping the definition and scope of the configuration parameters from the parameter definition file to the created stateflow blocks. The system logic 220 further connect 226 the created stateflow blocks to generate stateflow models. The connecting 226 may include identifying, for each pair of stateflow blocks the common parameter with scope. The connecting 226 may also include interconnecting, the software blocks, based on the identified common parameter to generate the stateflow model 230 till no further interconnection is possible.

[0023] The system 200 may also include capabilities for validating the generated stateflow model by simulation run of test data. The system 200 may further include displaying the generated stateflow model. The visualization can be either reports or dashboards based on the user requirements.

[0024] In practice, the systems shown herein, such as system 200 can be more complicated, with additional functionality, more complex inputs, and the like.

[0025] In any of the examples herein, the inputs, outputs and generated stateflow model 230 can be stored in one or more computer-readable storage media.

[0026] In any of the examples herein, software requirements may be a condition or capability needed by a user to solve a problem or achieve an objective. It may also be defined as a condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document. The software requirements may further be defined as a documented representation of a condition or capability as mentioned above.

[0027] The software requirements are typically maintained as Software requirement specification (SRS) in a documented form. A requirements specification for a software system, is a complete description of the behavior of a system to be developed and may include a set of use cases that describe interactions the users will have with the software. In addition it also contains non-functional requirements. Non-functional requirements impose constraints on the design or implementation (such as performance engineering requirements, quality standards, security concerns or design constraints).

[0028] The software requirements specification is written in natural English language. There are different styles of writing the SRS documents such as, procedural requirements, functions, scenarios, etc. More than 90% of the requirements in control software specification are procedural in nature. Such specifications contain two types of definitions: (i) Configuration parameters; and (ii) procedural statements. The configuration parameters are of four classes: (i-a) primary inputs or signals; (i-b) intermediate or state variables; (i-c) outputs; and (i-d) calibration parameters. A configuration parameter includes name, data type, and value range. Normally, the data type and value range associated to the input parameters are defined in a separate data file called signal data base file. Intermediate variables are defined in the requirement which consists of variable name, data type and variable state. On the other hand, calibration parameters are environment variables which can be configured within a specific range of values under different scenarios. The calibrations are separately listed in the configuration parameter database in a tabular form which contains calibration name, value range, offset and description. Constants hold fixed value throughout the specification. A procedural statement typically consists of a condition and a decision component. The condition components are functionally defined over the input parameters, state variables, calibration sets and constants with a set of logical operators. However, the decisions are defined over the output parameters, state variables and calibration sets with arithmetic operators. A procedural statement of instrument panel cluster unit (IPCU) from automotive vehicle has been presented below as follows:

[0029]

if Power mode is RUN
if Signal has been received exactly one time during current
ignition cycle then
Fuel_Level_Percent = FLPn
else if Signal been received at least two times during
current ignition cycle then
Fuel_Level_Percent (Y) = k × FLPn + (1 − k) × FLP(Y)n−1
else
Fuel_Level_Percent = 0
end if
end if
FLPn−1 = FLPn

[0030] It specifies the procedure for calculating the Fuel_Level_Percent based on current and previous values of the signal, FLP which is received from the corresponding bus signal of the IPC hardware. The FLP signal is essentially a vector consisting of signal status and value. The triggering condition for the calculation is dependent on power mode and the number of times the FLP signal has been received (i.e., status bit becomes active). The calculation also involves the calibration, fuel_level_percent_filter (k) whose range and type is defined in the parameter database file. The value of Fuel_Level_Percent is used for calculating the total fuel range as per the requirement. Example of parameter list for the procedural requirement is shown in Table 1.

[0031]

TABLE 1
Example of Configuration Parameter List with Description
Parameter	Parameter		Values/Value Range
Name	Type	Data Type	normal	min	max	offset
Power Mode	Input	Enumerated	Idle,	—	—	—
			Active,
			Crank,
			RUN
FLP	Input	Vector	—	—	—	—
		<status-
		bit, value>
		(Boolean,
		Float)
		status-bit	1/0	—	—	—
		value	—	0	100	—
Fuel_percent_	Calibration	Float	0.5	0.5	0.9	0.025
filter(k)
Fuel_Level_	State	Float	—	0	100	—
Percent	Variable
Ignition	input	Integer	300	300	420	—
cycle time		(milli-
		seconds)

[0032] The configuration parameter list is specified in a separate database file including the parameter type, data type and value ranges. Calibration parameter has an offset which indicates the tolerance with respect to its normal value.

[0033] In any of the examples herein, an annotated software requirement may include a labelled procedural statement stored with the definition and scope of the configuration parameters as a parameter definition file. The procedural statement is labelled with a unique identifier and may include at least one operator.

[0034] In any of the examples herein, a stateflow block is created when the annotated software requirements are parsed. The stateflow blocks may be created for the operators of the labelled procedural statement from the parameter definition file. These stateflow blocks are mapped to the definition and scope of the configuration parameters from the parameter definition file of the annotated software requirements.

[0035] In any of the examples herein, a stateflow model may be a visual model for capturing, analyzing, and implementing software requirements for delivering better results in the business.

[0036] The general process for generating stateflow model from software requirements is processing the software requirements to annotate and, parse them to create a plurality of stateflow blocks and then connecting these stateflow blocks to create a stateflow model.

[0037] The techniques and solutions described herein can be performed by software, hardware, or both of a computing environment, such as one or more computing devices. For example, computing devices include server computers, desktop computers, laptop computers, notebook computers, handheld devices, netbooks, tablet devices, mobile devices, PDAs, and other types of computing devices.

[0038] FIG. 3 illustrates a generalized example of a suitable computing environment 300 in which the described technologies can be implemented. The computing environment 300 is not intended to suggest any limitation as to scope of use or functionality, as the technologies may be implemented in diverse general-purpose or special-purpose computing environments. For example, the disclosed technology may be implemented using a computing device comprising a processing unit, memory, and storage storing computer-executable instructions implementing the enterprise computing platform technologies described herein. The disclosed technology may also be implemented with other computer system configurations, including hand held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, a collection of client/server systems, and the like. The disclosed technology may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices

[0039] With reference to FIG. 3, the computing environment 300 includes at least one processing unit 310 coupled to memory 320. In FIG. 8, this basic configuration 330 is included within a dashed line. The processing unit 310 executes computer-executable instructions and may be a real or a virtual processor. In a multi-processing system, multiple processing units execute computer-executable instructions to increase processing power. The memory 320 may be volatile memory (e.g., registers, cache, RAM), non-volatile memory (e.g., ROM, EEPROM, flash memory, etc.), or some combination of the two. The memory 320 can store software 380 implementing any of the technologies described herein.

[0040] A computing environment may have additional features. For example, the computing environment 300 includes storage 340, one or more input devices 350, one or more output devices 360, and one or more communication connections 370. An interconnection mechanism (not shown) such as a bus, controller, or network interconnects the components of the computing environment 300. Typically, operating system software (not shown) provides an operating environment for other software executing in the computing environment 300, and coordinates activities of the components of the computing environment 300.

[0041] The storage 340 may be removable or non-removable, and includes magnetic disks, magnetic tapes or cassettes, CD-ROMs, CD-RWs, DVDs, or any other computer-readable media which can be used to store information and which can be accessed within the computing environment 300. The storage 340 can store software 380 containing instructions for any of the technologies described herein.

[0042] The input device(s) 350 may be a touch input device such as a keyboard, mouse, pen, or trackball, a voice input device, a scanning device, or another device that provides input to the computing environment 300. For audio, the input device(s) 350 may be a sound card or similar device that accepts audio input in analog or digital form, or a CD-ROM reader that provides audio samples to the computing environment. The output device(s) 360 may be a display, printer, speaker, CD-writer, or another device that provides output from the computing environment 300.

[0043] The communication connection(s) 370 enable communication over a communication mechanism to another computing entity. The communication mechanism conveys information such as computer-executable instructions, audio/video or other information, or other data. By way of example, and not limitation, communication mechanisms include wired or wireless techniques implemented with an electrical, optical, RF, infrared, acoustic, or other carrier.

[0044] The techniques herein can be described in the general context of computer-executable instructions, such as those included in program modules, being executed in a computing environment on a target real or virtual processor. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, etc., that perform particular tasks or implement particular abstract data types. The functionality of the program modules may be combined or split between program modules as desired in various embodiments. Computer-executable instructions for program modules may be executed within a local or distributed computing environment.

[0045] Any of the storing actions described herein can be implemented by storing in one or more computer-readable media (e.g., computer-readable storage media or other tangible media).

[0046] Any of the things described as stored can be stored in one or more computer-readable media (e.g., computer-readable storage media or other tangible media).

[0047] Any of the methods described herein can be implemented by computer-executable instructions in (e.g., encoded on) one or more computer-readable media (e.g., computer-readable storage media or other tangible media). Such instructions can cause a computer to perform the method. The technologies described herein can be implemented in a variety of programming languages.

[0048] Any of the methods described herein can be implemented by computer-executable instructions stored in one or more computer-readable storage devices (e.g., memory, magnetic storage, optical storage, or the like). Such instructions can cause a computer to perform the method.

[0049] The technologies from any example can be combined with the technologies described in any one or more of the other examples. In view of the many possible embodiments to which the principles of the disclosed technology may be applied, it should be recognized that the illustrated embodiments are examples of the disclosed technology and should not be taken as a limitation on the scope of the disclosed technology. Rather, the scope of the disclosed technology includes what is covered by the following claims. We therefore claim as our invention all that comes within the scope and spirit of the claims.