CN116880803A - Modeling method and device of software service system, storage medium and electronic equipment - Google Patents

Modeling method and device of software service system, storage medium and electronic equipment Download PDF

Info

Publication number
CN116880803A
CN116880803A CN202310897470.1A CN202310897470A CN116880803A CN 116880803 A CN116880803 A CN 116880803A CN 202310897470 A CN202310897470 A CN 202310897470A CN 116880803 A CN116880803 A CN 116880803A
Authority
CN
China
Prior art keywords
state
software service
service system
sub
working
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202310897470.1A
Other languages
Chinese (zh)
Inventor
李桂
王卓成
罗剑平
李美娜
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Industrial and Commercial Bank of China Ltd ICBC
Original Assignee
Industrial and Commercial Bank of China Ltd ICBC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Industrial and Commercial Bank of China Ltd ICBC filed Critical Industrial and Commercial Bank of China Ltd ICBC
Priority to CN202310897470.1A priority Critical patent/CN116880803A/en
Publication of CN116880803A publication Critical patent/CN116880803A/en
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/10—Requirements analysis; Specification techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3604—Software analysis for verifying properties of programs
    • G06F11/3608—Software analysis for verifying properties of programs using formal methods, e.g. model checking, abstract interpretation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/31—Programming languages or programming paradigms
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Stored Programmes (AREA)

Abstract

The application discloses a modeling method and device of a software service system, a storage medium and electronic equipment. Relates to the field of cloud computing, and the method comprises the following steps: acquiring system requirements and a plurality of working phases of a software service system; extracting system behaviors of each working stage based on system requirements, wherein the system behaviors comprise input, response and output of each working stage of the software service system; generating a finite state automaton of the software service system through the system behavior of each working stage, wherein the finite state automaton is a state diagram description of the system behavior; verifying the finite state automaton through a form verifier to obtain a verification conclusion of the finite state automaton; and under the condition that the verification conclusion represents that the form verification of the finite state automaton is passed, determining a development model of the software service system based on the system behavior. The application solves the problem of poor ambiguity and accuracy of the development model of the software service system in the related technology.

Description

Modeling method and device of software service system, storage medium and electronic equipment
Technical Field
The application relates to the field of cloud computing, in particular to a modeling method and device of a software service system, a storage medium and electronic equipment.
Background
The service industry is transforming to modern service industry mainly comprising information and knowledge, with the development of technology, the service form appears from small to large and from simple to complex evolution process, the service composition is gradually complicated, and the relatively scattered service organization form in the organization unit of service providers is gradually developed into a complex service network facing the field, so as to form an integrated service ecological system. The software service engineering serves as a research field for discussing how to analyze, design, implement and manage a service system, and becomes one research focus in the field of cloud computing.
In the related art, the service splitting mode is mainly a domain driving design, the domain driving design is a division of a business layer, and comprises entity concepts, process concepts, attributes and methods, and is a collection of abstract concepts. From a demand model to a field model, the participation of field experts is needed, the field model has the characteristics of insufficient refining, ambiguity and inaccuracy, the understanding of the demands and the splitting of services by designers are influenced, and errors in the design stage have greater influence on the reliability and the safety of a functional system.
Aiming at the problem of poor ambiguity and accuracy of a development model of a software service system in the related technology, no effective solution is proposed at present.
Disclosure of Invention
The application mainly aims to provide a modeling method, a modeling device, a storage medium and electronic equipment of a software service system, so as to solve the problem that a development model of the software service system in the related technology is poor in ambiguity and accuracy.
To achieve the above object, according to one aspect of the present application, there is provided a modeling method of a software service system. The method comprises the following steps: acquiring system requirements and a plurality of working phases of a software service system, wherein the system requirements are used for describing system functions which the software service system needs to realize for providing software services, and the working phases are used for describing different working states in the process that the software service system realizes the system functions; extracting system behaviors of each working stage based on system requirements, wherein the system behaviors comprise input, response and output of each working stage of the software service system; generating a finite state automaton of the software service system through the system behavior of each working stage, wherein the finite state automaton is a state diagram description of the system behavior; verifying the finite state automaton through a form verifier to obtain a verification conclusion of the finite state automaton; and under the condition that the verification conclusion represents that the form verification of the finite state automaton is passed, determining a development model of the software service system based on the system behavior.
Optionally, extracting the system behavior for each working phase based on the system requirements includes: determining sub-requirements of each working stage in the system requirements, wherein the sub-requirements are used for describing system functions which are needed to be realized by the software service system for realizing the working state of the working stage; extracting sub-inputs, sub-responses and sub-outputs in each sub-requirement, and determining the association relation between the sub-outputs of each sub-requirement and the sub-inputs of other sub-requirements, wherein the other sub-requirements are sub-requirements except the sub-requirement in the working stage of the sub-requirement; and combining the sub-inputs, the sub-responses and the sub-outputs according to the association relation to obtain the inputs, the responses and the outputs of each working stage.
Optionally, generating the finite state automaton of the software service system by the system behavior of each working phase comprises: acquiring a system state of each working stage, wherein the system state comprises an initial state, an intermediate state and a target state set, the initial state is a system state before a software service system corresponding to sub-input realizes a system function, the intermediate state is a system state in the process of realizing the system function of the software service system corresponding to sub-response, the target state set comprises a plurality of target states, and the target state is a system state after the software service system corresponding to sub-output realizes the system function; determining conditions required for converting the initial state into each target state, and obtaining a condition set corresponding to the target state set; drawing a finite state automaton of each working stage according to the association relation among the initial state, the intermediate state and each target state in the target state set, wherein the association relation is the association relation between the sub-output of the sub-requirement and the sub-input of other sub-requirements; and combining the finite state automata of all working phases to obtain the finite state automata of the software service system.
Optionally, verifying the finite state automaton by the form verifier, and obtaining a verification conclusion of the finite state automaton includes: judging whether the system state of each working stage meets the assertion of the software service system; under the condition that the system states of all working phases meet the assertion of the software service system, judging whether the state transition from each initial state to the target state meets the system requirement or not; and under the condition that the state transition from all initial states to target states meets the system requirement, determining that the finite state automaton form verification passes.
Optionally, determining whether the system state of each working phase satisfies the assertion of the software service system includes: acquiring an expected system state of each working stage of the software service system; judging whether the system state of each working stage is the same as the expected system state; under the condition that the system state is the same as the expected system state, determining that the system state in the working stage meets the assertion of the software service system; in the event that the system state differs from the expected system state, it is determined that the system state of the operational phase does not satisfy the assertion of the software service system.
Optionally, determining whether the state transition of each initial state to the target state meets the system requirement includes: judging whether each condition in the condition set corresponds to only one target state or not; under the condition that at least one condition in the condition set corresponds to a plurality of target states, determining that the state transition from the initial state to the target state does not meet the system requirement; under the condition that all conditions in the condition set correspond to only one target state, judging whether all target states in the target state set can be successfully converted from the initial state; under the condition that at least one target state conversion failure exists in the target state set, determining that the state conversion from the initial state to the target state does not meet the system requirement; under the condition that all target states in the target state set can be successfully converted from the initial state, determining that the state conversion from the initial state to the target state meets the system requirement.
Optionally, after determining whether the system state of each working phase satisfies the assertion of the software service system, the method further includes: determining that the finite state automaton form verification fails in the case that the system state of at least one working stage does not meet the assertion of the software service system; after determining whether the state transition from each initial state to the target state meets the system requirement, the method further comprises: under the condition that the state transition from at least one initial state to a target state does not meet the system requirement, determining that the finite state automaton form verification fails; and re-executing the step of acquiring the system requirement and a plurality of working phases of the software service system under the condition that the verification conclusion represents that the finite state automaton form verification fails.
Optionally, determining the development model of the software service system based on the system behavior includes: determining a plurality of service modules which need to be provided by a software service system to realize each system behavior; acquiring development codes of each service module from a database; and combining the development codes of all the service modules to obtain a development model of the software service system.
To achieve the above object, according to another aspect of the present application, there is provided a modeling apparatus of a software service system. The device comprises: the system comprises an acquisition unit, a control unit and a control unit, wherein the acquisition unit is used for acquiring system requirements and a plurality of working phases of a software service system, the system requirements are used for describing system functions which the software service system needs to realize for providing software services, and the working phases are used for describing different working states in the process of the software service system realizing the system functions; an extraction unit for extracting system behavior of each working stage based on system requirements, wherein the system behavior comprises input, response and output of each working stage of the software service system; a generating unit, configured to generate a finite state automaton of the software service system through system behaviors of each working stage, where the finite state automaton is a state diagram description of the system behaviors; the verification unit is used for verifying the finite state automaton through the form verifier to obtain a verification conclusion of the finite state automaton; and the determining unit is used for determining a development model of the software service system based on the system behavior under the condition that the verification conclusion represents that the finite state automaton form verification passes.
According to the application, the following steps are adopted: acquiring system requirements and a plurality of working phases of a software service system, wherein the system requirements are used for describing system functions which the software service system needs to realize for providing software services, and the working phases are used for describing different working states in the process that the software service system realizes the system functions; extracting system behaviors of each working stage based on system requirements, wherein the system behaviors comprise input, response and output of each working stage of the software service system; generating a finite state automaton of the software service system through the system behavior of each working stage, wherein the finite state automaton is a state diagram description of the system behavior; verifying the finite state automaton through a form verifier to obtain a verification conclusion of the finite state automaton; under the condition that the verification conclusion represents that the finite state automaton form verification passes, a development model of the software service system is determined based on the system behavior, and the problem that the development model of the software service system in the related technology is poor in ambiguity and accuracy is solved. The finite state automaton is generated based on the system requirements of the software service system, the finite state automaton is verified through the form verifier, and under the condition that verification is passed, the development model of the software service system is determined based on the system behavior, so that the effects of achieving the ambiguity of the development model of the software service system and improving the accuracy are achieved.
Drawings
The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this specification, illustrate embodiments of the application and together with the description serve to explain the application. In the drawings:
FIG. 1 is a flow chart of a modeling method for a software service system provided in accordance with an embodiment of the present application;
FIG. 2 is a schematic diagram of a finite state automaton of a software service system providing system demand for product reddening in accordance with an embodiment of the present application;
FIG. 3 is a flow chart of an alternative modeling method for a software service system provided in accordance with an embodiment of the present application;
FIG. 4 is a schematic diagram of a modeling apparatus for a software service system provided in accordance with an embodiment of the present application;
fig. 5 is a schematic diagram of an electronic device according to an embodiment of the present application.
Detailed Description
It should be noted that, without conflict, the embodiments of the present application and features of the embodiments may be combined with each other. The application will be described in detail below with reference to the drawings in connection with embodiments.
In order that those skilled in the art will better understand the present application, a technical solution in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in which it is apparent that the described embodiments are only some embodiments of the present application, not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the present application without making any inventive effort, shall fall within the scope of the present application.
It should be noted that the terms "first," "second," and the like in the description and the claims of the present application and the above figures are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate in order to describe the embodiments of the application herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.
It should be noted that, the user information (including, but not limited to, user equipment information, user personal information, etc.) and the data (including, but not limited to, data for presentation, analyzed data, etc.) related to the present disclosure are information and data authorized by the user or sufficiently authorized by each party.
The application will be described with reference to preferred implementation steps, and fig. 1 is a flowchart of a modeling method of a software service system according to an embodiment of the application, as shown in fig. 1, and the method includes the following steps:
Step S101, acquiring a system requirement of a software service system and a plurality of working phases, wherein the system requirement is used for describing a system function which needs to be implemented by the software service system for providing a software service, and the working phases are used for describing different working states in the process of implementing the system function by the software service system.
Specifically, the software service system may be a financial software system being developed by a financial institution, where the system requirements include a functional requirement and a non-functional requirement, and the system requirements of the software service system are analyzed to divide a working phase of the system, where the working phase is also a basis of a subsequent service division, and the system requirements of the software service system define software functions that a developer needs to implement by the software service system, and a user gradually transitions from an initial state to a target state of the software service system through the software functions to implement the given software functions, so the software requirements may be regarded as a series of state changes of a software system process, and the working phase of the software service system may be divided into: software state 1-software state 2- … … -software state N, wherein the transition between software states is implemented by a state transition function.
It should be noted that, the system requirement is composed of software service activities with different levels and different relations, and the working phases are divided according to the system requirement of the software service system according to the time series relation or the space parallel relation. Series relationship (AND): for the user role, each step of a single software service provision must be completed to achieve the goal, a common tandem relationship is sequential tandem SAND (Sequence AND), which requires each step to be completed in a specific order. Parallel relationship (OR): for the user role, the purpose of the demand target can be achieved by using one of the software service functions.
For example, taking the < product split > functional requirement as an example, describing the process of software service modeling and splitting, the requirement process mainly includes three phases: 1) Creating a product; 2) Setting a red dividing mode by a client; 3) And registering the system in a red mode. The three stages can be provided by different software services, a serial relation is formed between the three stages, and a client sets a red-sharing mode, the red-sharing mode can be set when a product is purchased, the red-sharing mode can also be set when a warehouse is taken for inquiring, and a parallel relation is formed between different red-sharing modes.
Step S102, extracting system behaviors of each working stage based on the system requirements, wherein the system behaviors comprise input, response and output of each working stage of the software service system.
Specifically, system behavior of the software service system is extracted according to system requirements and working phases, and the system behavior comprises input, response and output. The implementation of system behavior is accomplished by software states and state transition functions, so the process of extracting system behavior is also the process of analyzing the functions of the software service system. The system behavior is a detailed description of potential software services and is also the basis for the next generation of finite state automata.
For example, the input corresponding to the working stage of the customer setting and dividing method is the output of the product creating stage, that is, the created product is used as the input of the working stage of the customer setting and dividing method, the product is set when the customer is underway, or the dividing method is set as the response when the customer is in the warehouse holding inquiry, and the completed dividing method is set as the output.
Step S103, generating a finite state automaton of the software service system through the system behavior of each working stage, wherein the finite state automaton is a state diagram description of the system behavior.
In particular, a finite state automaton is a state diagram description of the behavior of a system. The method comprises the steps of starting an initial state of a software service system to completing the work of the software service system, wherein input of each working stage of the software service system forms input of a state transition diagram, the system state is a snapshot of the software service system under a certain condition, and transition among different system states is realized through a state transition function.
And step S104, verifying the finite state automaton through a form verifier to obtain a verification conclusion of the finite state automaton.
In particular, a formal verifier is a tool for verifying a software service system or software design that can check design specifications, logic, and constraints to ensure that the software service system can function in an intended manner. And outputting a verification conclusion after verification by a form verifier according to the functions of state conversion, assertion and the like of the finite state automaton.
Step S105, determining a development model of the software service system based on the system behavior under the condition that the verification conclusion represents that the finite state automaton form verification is passed.
Specifically, if the verification conclusion shows that the design specification, logic and constraint conditions of the finite state automaton are not problematic, the situation that ambiguity or unreachable state exists among the system states is not existed, the verification is passed, then a split service list is output based on the system behaviors, namely the system behaviors of all working phases are further divided in detail, a service development model required by finer service in the working phases is determined, and the split service list is generated and used as a development model of a software service system.
According to the modeling method of the software service system, provided by the embodiment of the application, the system requirements and a plurality of working phases of the software service system are acquired, wherein the system requirements are used for describing the system functions which the software service system needs to realize for providing the software service, and the working phases are used for describing different working states in the process of realizing the system functions of the software service system; extracting system behaviors of each working stage based on system requirements, wherein the system behaviors comprise input, response and output of each working stage of the software service system; generating a finite state automaton of the software service system through the system behavior of each working stage, wherein the finite state automaton is a state diagram description of the system behavior; verifying the finite state automaton through a form verifier to obtain a verification conclusion of the finite state automaton; under the condition that the verification conclusion represents that the finite state automaton form verification passes, a development model of the software service system is determined based on the system behavior, and the problem that the development model of the software service system in the related technology is poor in ambiguity and accuracy is solved. The finite state automaton is generated based on the system requirements of the software service system, the finite state automaton is verified through the form verifier, and under the condition that verification is passed, the development model of the software service system is determined based on the system behavior, so that the effects of achieving the ambiguity of the development model of the software service system and improving the accuracy are achieved.
In the modeling method of the software service system provided by the embodiment of the application, the system behavior of each working stage is extracted based on the system requirements, which comprises the following steps: determining sub-requirements of each working stage in the system requirements, wherein the sub-requirements are used for describing system functions which are needed to be realized by the software service system for realizing the working state of the working stage; extracting sub-inputs, sub-responses and sub-outputs in each sub-requirement, and determining the association relation between the sub-outputs of each sub-requirement and the sub-inputs of other sub-requirements, wherein the other sub-requirements are sub-requirements except the sub-requirement in the working stage of the sub-requirement; and combining the sub-inputs, the sub-responses and the sub-outputs according to the association relation to obtain the inputs, the responses and the outputs of each working stage.
For example, the system requirement provides the software service system with the < product scoring > function, and three working phases of product creation, customer set scoring mode and system scoring registration are performed on the < product scoring > function by analyzing the system requirement. Each working stage has own sub-requirement, for example, the sub-requirement of the working stage of the client setting the reddening mode is that a reddening mode is set, the sub-input of the sub-requirement can be the user input reddening parameter, the sub-response is that the software service system configures the parameter in the < product reddening > function based on the reddening parameter input by the user, and the sub-output is the reddening mode set by the software service system.
Each working stage can contain a plurality of sub-demands, and the sub-demands have an association relationship, wherein the association relationship can be a time sequence or a space parallel relationship. For example, the working stage of setting the red-sharing mode may include sub-requirements of setting the red-sharing parameter, setting the red-sharing time, setting the red-sharing proportion, and the like, and then the setting the red-sharing time and the setting the red-sharing proportion may be in a parallel relationship, and the setting the red-sharing time or the setting the red-sharing proportion and the setting the red-sharing parameter are in a time-sequential relationship of setting the red-sharing time or the red-sharing proportion first and then the red-sharing parameter. The output of sub-requirements such as the setting of the time for dividing and the setting of the proportion for dividing corresponds to the input of the sub-requirements of the configuration dividing parameter, and different sub-requirements in the same working stage are combined through the association relation, so that the input, response and output of each working stage are finally obtained. The data is provided for drawing finite state automata by extracting the system behavior for each working phase based on system requirements.
Optionally, in the modeling method of a software service system provided by the embodiment of the present application, the generating the finite state automaton of the software service system by the system behavior of each working stage includes: acquiring a system state of each working stage, wherein the system state comprises an initial state, an intermediate state and a target state set, the initial state is a system state before a software service system corresponding to sub-input realizes a system function, the intermediate state is a system state in the process of realizing the system function of the software service system corresponding to sub-response, the target state set comprises a plurality of target states, and the target state is a system state after the software service system corresponding to sub-output realizes the system function; determining conditions required for converting the initial state into each target state, and obtaining a condition set corresponding to the target state set; drawing a finite state automaton of each working stage according to the association relation among the initial state, the intermediate state and each target state in the target state set, wherein the association relation is the association relation between the sub-output of the sub-requirement and the sub-input of other sub-requirements; and combining the finite state automata of all working phases to obtain the finite state automata of the software service system.
Specifically, since the state of the software service system is finite and definable, the system analyst can build a finite state automaton of the software service system through the DFA algorithm (Deterministic Finite Automation, deterministic finite automaton algorithm) to describe the state change of the software service system as the basis for the software service design and development. The DFA describing the software service process is defined as g= { K, Σ, F, S, Z }, where K is a finite set, each element of which represents a state of the software service system, the system state refers to a snapshot of the system at a certain moment, each system state has to satisfy a defined boolean expression, i.e. the system assertion, the system state comprises an initial state F, an intermediate state S and a target state set Z, Σ represents a set of conditions that may occur for the software service system; f is a single value mapping from kχΣ to K, F (s, a) =s 'indicating that the current system state is s, and when condition a is encountered, transition to the subsequent state s'. The state transition condition may be defined as a software functional activity, which is a set of functions of different levels for the system, which may be refined at the time of demand analysis and aggregated at the time of function implementation. Form verification is performed by generating a finite state automaton, so that the problems of inaccuracy and ambiguity of a development model of a software service system are avoided.
For example, fig. 2 is a schematic diagram of a finite state automaton of a software service system with a system requirement of product reddening according to an embodiment of the present application, as shown in fig. 2, si represents a system state, where S1 represents an initial state, S2 represents an intermediate state to complete product creation, S3 represents an intermediate state client to set a reddening manner, S4 represents a target state to complete product reddening, and a function end state. Ei represents a conversion action, wherein E1: (service) setting parameters, E2: (customer) purchase setup reddening mode, E3: (customer) holding warehouse inquiry setting and dividing method, E4: (System) registration of the score. The modeling method of the software service system is described above by taking the use case < product redness > as an example. By introducing a service modeling method in the system development process, the system function requirements can be converted into finite automaton state diagram description, and a form verification conclusion and a split service list are output to serve as the basis for software service design and development. The state conversion is described and verified according to the time series relation or the space parallel relation specification by using the characteristics of state conversion, assertion, state accessibility and the like of the finite state automaton, and consistency, ambiguity and integrity of the requirement-to-service conversion are realized.
Optionally, in the modeling method of the software service system provided by the embodiment of the present application, the verification of the finite state automaton by the form verifier, the obtaining the verification conclusion of the finite state automaton includes: judging whether the system state of each working stage meets the assertion of the software service system; under the condition that the system states of all working phases meet the assertion of the software service system, judging whether the state transition from each initial state to the target state meets the system requirement or not; and under the condition that the state transition from all initial states to target states meets the system requirement, determining that the finite state automaton form verification passes.
Specifically, the assertion is used for checking the correctness of a specific condition in the running process of the finite state automaton, interrupting the running of the finite state automaton when the condition is not satisfied, and giving corresponding error prompt information. Checking the validity of input parameters by assertions, detecting logic errors in the program, verifying the correctness of the program output, etc. For the situations that the verification such as divergence and unreachable state of the finite state automaton is not passed, the system state is not satisfied with the assertion of the software service system, and the system analysis is required to be carried out again to eliminate ambiguity and incompleteness, and under the conditions that the system state in all working phases satisfies the assertion of the software service system and the state transition from all initial states to target states accords with the system requirement. And determining that the finite state automaton form passes the verification. And verifying the finite state automaton through a form verification machine to eliminate ambiguity and incompleteness of the finite state automaton.
Optionally, in the modeling method of a software service system provided by the embodiment of the present application, determining whether the system state of each working stage meets the assertion of the software service system includes: acquiring an expected system state of each working stage of the software service system; judging whether the system state of each working stage is the same as the expected system state; under the condition that the system state is the same as the expected system state, determining that the system state in the working stage meets the assertion of the software service system; in the event that the system state differs from the expected system state, it is determined that the system state of the operational phase does not satisfy the assertion of the software service system.
In particular, the expected system state may be the system state at which the developer expects the software service system to fulfill the system requirements. Judging whether the system state of each working stage of the software service system is the same as the expected system state or not through a form verifier, if the system state of each working stage is the same as the expected system state, indicating that the system state meets the assertion of the software service system, and if the system state of at least one working stage is different from the expected system state, indicating that the system state does not meet the assertion of the software service system. And determining whether a development model corresponding to the finite state automaton of the software service system can be realized by judging whether the system state of each working stage meets the assertion of the software service system.
Optionally, in the modeling method of a software service system provided by the embodiment of the present application, determining whether the state transition from each initial state to the target state meets the system requirement includes: judging whether each condition in the condition set corresponds to only one target state or not; under the condition that at least one condition in the condition set corresponds to a plurality of target states, determining that the state transition from the initial state to the target state does not meet the system requirement; under the condition that all conditions in the condition set correspond to only one target state, judging whether all target states in the target state set can be successfully converted from the initial state; under the condition that at least one target state conversion failure exists in the target state set, determining that the state conversion from the initial state to the target state does not meet the system requirement; under the condition that all target states in the target state set can be successfully converted from the initial state, determining that the state conversion from the initial state to the target state meets the system requirement.
Specifically, if each condition corresponds to only one target state, it indicates that the finite state automaton of the software service system has no divergence, that is, the software service system has ambiguity, and if at least one condition corresponds to a plurality of target states, it indicates that the finite state automaton of the software service system has divergence, that is, the development model of the software service system has a problem. Whether all target states in the target state set can be successfully converted from the initial state is judged to determine whether all target states in the finite state automaton of the software service system are reachable, and if at least one target state cannot be successfully converted, the finite state automaton of the software service system is incomplete, namely, a development model of the software service system has a problem. And determining whether a development model corresponding to the finite state automaton of the software service system can be realized by judging whether the state transition from each initial state to the target state meets the system requirement or not.
Optionally, in the modeling method of a software service system provided by the embodiment of the present application, after determining whether the system state of each working stage meets the assertion of the software service system, the method further includes: determining that the finite state automaton form verification fails in the case that the system state of at least one working stage does not meet the assertion of the software service system; after determining whether the state transition from each initial state to the target state meets the system requirement, the method further comprises: under the condition that the state transition from at least one initial state to a target state does not meet the system requirement, determining that the finite state automaton form verification fails; and re-executing the step of acquiring the system requirement and a plurality of working phases of the software service system under the condition that the verification conclusion represents that the finite state automaton form verification fails.
Specifically, if verification of the finite state automaton by the form verifier fails, it is indicated that the technical problem of the development model corresponding to the finite state automaton cannot be achieved, so that the system requirement needs to be analyzed again, and steps of obtaining the system requirement of the software service system, a plurality of working stages and the like are executed again to repartition the working stages and draw the finite state automaton. Until the verification of the newly drawn finite state automaton passes, determining that a development model of the software service system can be realized.
Optionally, in the modeling method of a software service system provided by the embodiment of the present application, determining a development model of the software service system based on system behavior includes: determining a plurality of service modules which need to be provided by a software service system to realize each system behavior; acquiring development codes of each service module from a database; and combining the development codes of all the service modules to obtain a development model of the software service system.
Specifically, under the condition that the verification of the finite state automaton is passed, a development model for explaining the software service system can be realized, and at the moment, each system behavior is refined step by step, and the system behavior of each working stage is further split into a plurality of service modules which can be realized. And acquiring the development codes of each service module, and summarizing the development codes of all the service modules to obtain a development model of the software service system. For example, the split service list finally output by the software service system with the system demand of product splitting is: e1: (service) setting parameters, E2: (customer) purchase setup reddening mode, E3: (customer) holding warehouse inquiry setting and dividing method, E4: (System) registration of the score. By introducing a software service modeling method in the system analysis process of the software service system, various system requirements submitted by a user are formalized, service discovery, service design and service combination are further carried out, and meanwhile, the system can also be used as the basis of developer and test delivery verification. And establishing a theoretical model of the software service by using a finite state automaton, formally modeling the demand use case by using the state, the assertion and the conversion function of the model, and carrying out service discovery, service design and service combination on the basis.
According to another embodiment of the present application, an alternative modeling method of a software service system is provided, and fig. 3 is a flowchart of an alternative modeling method of a software service system according to an embodiment of the present application. As shown in fig. 3, the method includes:
in step S301, the system requirements of the financial software system are analyzed, and the working phases of the financial software system are divided.
Specifically, the system requirements include functional requirements, non-functional requirements, and the like, and the most important work in the system analysis is the division of the working phases of the system, which are also the basis for the subsequent service division, and the working phases of the system can be divided into: software state 1→software state 2→software state N, wherein the transition between states is achieved by a state transition function.
Step S302, extracting the system behavior of the financial software system according to the system requirements and the system working stage.
Specifically, system behavior includes system inputs, responses, and outputs. The realization of the system behavior is completed by the software state and state transition function, and the process of extracting the system behavior is also the process of analyzing the software service function. The system behavior description is a detailed description of potential software services and is also the basis for the generation of the next finite state automata.
Step S303, generating a finite state automaton based on the system behavior of the financial software system.
In particular, a finite state automaton is a state diagram description of the behavior of a system. From the initial start of the system to the completion of the system work, the inputs of each stage of the financial system form the inputs of a state transition diagram, the software states are snapshots of the system under a certain condition, and the transition between different software states is realized through a state transition function.
And step S304, verifying the finite state automaton through a form verifier to obtain a verification conclusion.
Specifically, the finite state automaton is verified according to the functions of state transition, assertion and the like of the finite state automaton, and the form verifier outputs a verification conclusion.
Step S305, after verification, a resolved service list is generated and used as the basis for software service development.
Specifically, under the condition that the verification of the finite state automaton is passed, a development model for explaining the software service system can be realized, and at the moment, each system behavior is refined step by step, and the system behavior of each working stage is further split into a plurality of service modules which can be realized. And acquiring the development codes of each service module, and summarizing the development codes of all the service modules to obtain a development model of the software service system.
By the modeling method of the optional software service system provided by the embodiment of the application, the state, the assertion and the conversion function of the finite state automaton model are utilized to perform formal modeling on the demand case, and service discovery, service design and service combination are performed on the basis, so that various errors of the traditional field model are avoided, and consistency, disambiguation and integrity of contents such as part service splitting are realized.
It should be noted that the steps illustrated in the flowcharts of the figures may be performed in a computer system such as a set of computer executable instructions, and that although a logical order is illustrated in the flowcharts, in some cases the steps illustrated or described may be performed in an order other than that illustrated herein.
The embodiment of the application also provides a modeling device of the software service system, and the modeling device of the software service system can be used for executing the modeling method for the software service system. The following describes a modeling apparatus of a software service system provided by an embodiment of the present application.
Fig. 4 is a schematic diagram of a modeling apparatus of a software service system according to an embodiment of the present application. As shown in fig. 4, the apparatus includes:
An obtaining unit 10, configured to obtain a system requirement of a software service system and a plurality of working phases, where the system requirement is used to describe a system function that needs to be implemented by the software service system for providing a software service, and the working phases are used to describe different working states in a process that the software service system implements the system function;
an extracting unit 20 for extracting a system behavior of each working phase based on a system requirement, wherein the system behavior includes an input, a response, and an output of each working phase of the software service system;
a generating unit 30, configured to generate a finite state automaton of the software service system through a system behavior of each working stage, where the finite state automaton is a state diagram description of the system behavior;
a verification unit 40, configured to verify the finite state automaton through a form verifier, so as to obtain a verification conclusion of the finite state automaton;
a first determining unit 50 for determining a development model of the software service system based on the system behavior in case the verification conclusion characterizes the verification of the finite state automaton form.
According to the modeling device of the software service system, provided by the embodiment of the application, the system requirements and a plurality of working phases of the software service system are acquired through the acquisition unit 10, wherein the system requirements are used for describing the system functions which the software service system needs to realize for providing the software service, and the working phases are used for describing different working states in the process of realizing the system functions of the software service system; an extraction unit 20 that extracts a system behavior of each working phase based on a system demand, wherein the system behavior includes an input, a response, and an output of each working phase of the software service system; a generation unit 30 that generates a finite state automaton of the software service system by the system behavior of each working phase, wherein the finite state automaton is a state diagram description of the system behavior; a verification unit 40 for verifying the finite state automaton through a form verifier to obtain a verification conclusion of the finite state automaton; the first determining unit 50 determines a development model of the software service system based on the system behavior under the condition that the verification conclusion represents that the form verification of the finite state automaton is passed, solves the problem that the development model of the software service system in the related art is poor in ambiguity and accuracy, and verifies the finite state automaton by a form verifier through generating the finite state automaton based on the system requirement of the software service system, and determines the development model of the software service system based on the system behavior under the condition that the verification is passed, thereby achieving the effects of achieving the ambiguity of the development model of the software service system and improving the accuracy.
Optionally, in the modeling apparatus of a software service system provided in the embodiment of the present application, the extracting unit 20 includes: the first determining module is used for determining sub-requirements of each working stage in the system requirements, wherein the sub-requirements are used for describing system functions which the software service system needs to realize for realizing the working state of the working stage; the extraction module is used for extracting sub-inputs, sub-responses and sub-outputs in each sub-requirement, and determining the association relation between the sub-outputs of each sub-requirement and the sub-inputs of other sub-requirements, wherein the other sub-requirements are sub-requirements except the sub-requirement in the working stage of the sub-requirement; and the first combination module is used for combining the sub-inputs, the sub-responses and the sub-outputs according to the association relation to obtain the inputs, the responses and the outputs of each working stage.
Optionally, in the modeling apparatus of a software service system provided in the embodiment of the present application, the generating unit 30 includes: the system comprises a first acquisition module, a second acquisition module and a third acquisition module, wherein the first acquisition module is used for acquiring a system state of each working stage, the system state comprises an initial state, an intermediate state and a target state set, the initial state is a system state before a software service system corresponding to sub-input realizes a system function, the intermediate state is a system state in the process of realizing the system function of the software service system corresponding to sub-response, the target state set comprises a plurality of target states, and the target state is a system state after the software service system corresponding to sub-output realizes the system function; the second determining module is used for determining conditions required by converting the initial state into each target state and obtaining a condition set corresponding to the target state set; the drawing module is used for drawing the finite state automaton of each working stage according to the association relation among the initial state, the intermediate state and each target state in the target state set, wherein the association relation is the association relation between the sub-output of the sub-requirement and the sub-input of other sub-requirements; and the second combination module is used for combining the finite state automata of all working phases to obtain the finite state automata of the software service system.
Optionally, in the modeling apparatus of a software service system provided in the embodiment of the present application, the verification unit 40 includes: the first judging module is used for judging whether the system state of each working stage meets the assertion of the software service system or not; the second judging module is used for judging whether the state transition from each initial state to the target state meets the system requirement or not under the condition that the system states of all working phases meet the assertion of the software service system; and the third determining module is used for determining that the form verification of the finite state automaton passes under the condition that the state transition from all the initial states to the target states meets the system requirement.
Optionally, in the modeling apparatus for a software service system provided in the embodiment of the present application, the first judging module includes: an acquisition sub-module for acquiring an expected system state of each working phase of the software service system; the first judging submodule is used for judging whether the system state of each working stage is the same as the expected system state; a first determining submodule, configured to determine that a system state in a working phase meets an assertion of a software service system when the system state is the same as an expected system state; and the second determining submodule is used for determining that the system state of the working stage does not meet the assertion of the software service system in the case that the system state is different from the expected system state.
Optionally, in the modeling apparatus for a software service system provided by the embodiment of the present application, the second judging module includes: the second judging submodule is used for judging whether each condition in the condition set corresponds to only one target state or not; a third determining submodule, configured to determine that, when at least one condition in the condition set exists and corresponds to a plurality of target states, state transition from the initial state to the target state does not meet a system requirement; the third judging sub-module is used for judging whether all the target states in the target state set can be successfully converted from the initial state under the condition that all the conditions in the condition set correspond to only one target state; a fourth determining submodule, configured to determine that, when at least one target state transition failure exists in the target state set, state transition from the initial state to the target state does not meet a system requirement; and the fifth determining submodule is used for determining that the state transition from the initial state to the target state meets the system requirement under the condition that all target states in the target state set can be successfully converted from the initial state.
Optionally, in the modeling apparatus of a software service system provided by the embodiment of the present application, the apparatus further includes: a second determining unit, configured to determine that the finite state automaton form verification fails in a case where a system state in at least one working phase does not satisfy an assertion of the software service system; the apparatus further comprises: a third determining unit, configured to determine that the finite state automaton form verification fails when there is at least one state transition from the initial state to the target state that does not meet the system requirement; and the execution unit is used for re-executing the step of acquiring the system requirement and a plurality of working phases of the software service system under the condition that the verification conclusion represents that the finite state automaton form verification fails.
Optionally, in the modeling apparatus of a software service system provided in the embodiment of the present application, the first determining unit 50 includes: a fourth determining module, configured to determine a plurality of service modules that need to be provided by the software service system to implement each system behavior; the second acquisition module is used for acquiring the development code of each service module from the database; and the third combination module is used for combining the development codes of all the service modules to obtain a development model of the software service system.
The modeling apparatus of the software service system includes a processor and a memory, the above-described acquisition unit 10, extraction unit 20, generation unit 30, verification unit 40, first determination unit 50, and the like are stored as program units in the memory, and the above-described program units stored in the memory are executed by the processor to realize the corresponding functions.
The processor includes a kernel, and the kernel fetches the corresponding program unit from the memory. The kernel can be provided with one or more, and the ambiguity of the development model of the software service system is realized and the accuracy is improved by adjusting the kernel parameters.
The memory may include volatile memory, random Access Memory (RAM), and/or nonvolatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM), among other forms in computer readable media, the memory including at least one memory chip.
The embodiment of the application provides a computer readable storage medium, on which a program is stored, which when executed by a processor, implements a modeling method for a software service system.
The embodiment of the application provides a processor, which is used for running a program, wherein the program runs to execute a modeling method of a software service system.
Fig. 5 is a schematic diagram of an electronic device according to an embodiment of the present application. As shown in fig. 5, the electronic device 501 includes a processor, a memory, and a program stored on the memory and executable on the processor, and when the processor executes the program, the following steps are implemented: acquiring system requirements and a plurality of working phases of a software service system, wherein the system requirements are used for describing system functions which the software service system needs to realize for providing software services, and the working phases are used for describing different working states in the process that the software service system realizes the system functions; extracting system behaviors of each working stage based on system requirements, wherein the system behaviors comprise input, response and output of each working stage of the software service system; generating a finite state automaton of the software service system through the system behavior of each working stage, wherein the finite state automaton is a state diagram description of the system behavior; verifying the finite state automaton through a form verifier to obtain a verification conclusion of the finite state automaton; and under the condition that the verification conclusion represents that the form verification of the finite state automaton is passed, determining a development model of the software service system based on the system behavior. The device herein may be a server, PC, PAD, cell phone, etc.
The application also provides a computer program product adapted to perform, when executed on a data processing device, a program initialized with the method steps of: acquiring system requirements and a plurality of working phases of a software service system, wherein the system requirements are used for describing system functions which the software service system needs to realize for providing software services, and the working phases are used for describing different working states in the process that the software service system realizes the system functions; extracting system behaviors of each working stage based on system requirements, wherein the system behaviors comprise input, response and output of each working stage of the software service system; generating a finite state automaton of the software service system through the system behavior of each working stage, wherein the finite state automaton is a state diagram description of the system behavior; verifying the finite state automaton through a form verifier to obtain a verification conclusion of the finite state automaton; and under the condition that the verification conclusion represents that the form verification of the finite state automaton is passed, determining a development model of the software service system based on the system behavior.
It will be appreciated by those skilled in the art that embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
In one typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include volatile memory in a computer-readable medium, random Access Memory (RAM) and/or nonvolatile memory, etc., such as Read Only Memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.
Computer readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by a computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.
It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article or apparatus that comprises an element.
It will be appreciated by those skilled in the art that embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
The foregoing is merely exemplary of the present application and is not intended to limit the present application. Various modifications and variations of the present application will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement, etc. which come within the spirit and principles of the application are to be included in the scope of the claims of the present application.

Claims (11)

1. A method of modeling a software service system, comprising:
acquiring system requirements of a software service system and a plurality of working phases, wherein the system requirements are used for describing system functions which the software service system needs to realize for providing software services, and the working phases are used for describing different working states in the process that the software service system realizes the system functions;
extracting system behaviors of each working stage based on the system requirements, wherein the system behaviors comprise input, response and output of each working stage of the software service system;
generating a finite state automaton of the software service system through system behaviors of each working stage, wherein the finite state automaton is a state diagram description of the system behaviors;
verifying the finite state automaton through a form verifier to obtain a verification conclusion of the finite state automaton;
and determining a development model of the software service system based on the system behavior under the condition that the verification conclusion characterizes the verification of the finite state automaton form.
2. The method of claim 1, wherein extracting system behavior for each working phase based on the system requirements comprises:
Determining sub-requirements of each working stage in the system requirements, wherein the sub-requirements are used for describing system functions which the software service system needs to realize for realizing the working state of the working stage;
extracting sub-inputs, sub-responses and sub-outputs in each sub-requirement, and determining the association relation between the sub-outputs of each sub-requirement and the sub-inputs of other sub-requirements, wherein the other sub-requirements are sub-requirements except for the sub-requirement in the working stage of the sub-requirement;
and combining the sub-input, the sub-response and the sub-output according to the association relation to obtain the input, the response and the output of each working stage.
3. The method of claim 1, wherein generating a finite state automaton of the software service system by system behavior of each working phase comprises:
acquiring a system state of each working stage, wherein the system state comprises an initial state, an intermediate state and a target state set, the initial state is the system state before the software service system corresponding to the sub-input realizes the system function, the intermediate state is the system state in the process of the software service system corresponding to the sub-response realizes the system function, the target state set comprises a plurality of target states, and the target state is the system state after the software service system corresponding to the sub-output realizes the system function;
Determining conditions required by the initial state to be converted into each target state, and obtaining a condition set corresponding to the target state set;
drawing a finite state automaton of each working stage according to the association relation among the initial state, the intermediate state and each target state in the target state set, wherein the association relation is the association relation between sub-output of sub-requirements and sub-input of other sub-requirements;
and combining the finite state automata of all working phases to obtain the finite state automata of the software service system.
4. The method of claim 3, wherein validating the finite state automaton by a formal validator to arrive at a validation conclusion for the finite state automaton comprises:
judging whether the system state of each working stage meets the assertion of the software service system;
judging whether the state transition from each initial state to a target state meets the system requirement or not under the condition that the system states in all working phases meet the assertion of the software service system;
and under the condition that the state transition from all initial states to target states meets the system requirement, determining that the finite state automaton form verification passes.
5. The method of claim 4, wherein determining whether the system state of each working phase satisfies the assertion of the software service system comprises:
acquiring an expected system state of each working stage of the software service system;
judging whether the system state of each working stage is the same as the expected system state;
determining that the system state of the working phase meets the assertion of the software service system under the condition that the system state is the same as the expected system state;
in the event that the system state is different from the expected system state, determining that the system state of the operational phase does not satisfy the assertion of the software service system.
6. The method of claim 4, wherein determining whether each initial state-to-target state transition meets the system requirements comprises:
judging whether each condition in the condition set corresponds to only one target state or not;
under the condition that at least one condition in the condition set corresponds to a plurality of target states, determining that the state transition from the initial state to the target state does not meet the system requirement;
under the condition that all conditions in the condition set correspond to only one target state, judging whether all target states in the target state set can be successfully converted from the initial state;
Under the condition that at least one target state conversion failure exists in the target state set, determining that the state conversion from the initial state to the target state does not meet the system requirement;
and under the condition that all target states in the target state set can be successfully converted from the initial state, determining that the state conversion from the initial state to the target state meets the system requirement.
7. The method of claim 4, wherein after determining whether the system state of each working phase satisfies the assertion of the software service system, the method further comprises:
determining that the finite state automaton form verification fails in the case that the system state of at least one working stage does not meet the assertion of the software service system;
after determining whether the state transition from each initial state to the target state meets the system requirements, the method further comprises:
determining that the finite state automaton form verification fails under the condition that at least one state transition from an initial state to a target state does not meet the system requirements;
and re-executing the step of acquiring the system requirement and a plurality of working phases of the software service system under the condition that the verification conclusion represents that the finite state automaton form verification fails.
8. The method of claim 1, wherein determining a development model of the software service system based on the system behavior comprises:
determining a plurality of service modules which need to be provided by the software service system to realize each system behavior;
acquiring development codes of each service module from a database;
and combining the development codes of all the service modules to obtain a development model of the software service system.
9. A modeling apparatus for a software service system, comprising:
the system comprises an acquisition unit, a control unit and a control unit, wherein the acquisition unit is used for acquiring system requirements of a software service system and a plurality of working phases, the system requirements are used for describing system functions which the software service system needs to realize for providing software services, and the working phases are used for describing different working states in the process of the software service system realizing the system functions;
an extraction unit, configured to extract a system behavior of each working phase based on the system requirement, where the system behavior includes an input, a response, and an output of each working phase of the software service system;
a generating unit, configured to generate a finite state automaton of the software service system through a system behavior of each working stage, where the finite state automaton is a state diagram description of the system behavior;
The verification unit is used for verifying the finite state automaton through a form verifier to obtain a verification conclusion of the finite state automaton;
and the determining unit is used for determining a development model of the software service system based on the system behavior under the condition that the verification conclusion characterizes the verification of the finite state automaton form to pass.
10. A non-volatile storage medium, characterized in that the non-volatile storage medium comprises a stored program, wherein the program, when run, controls a device in which the non-volatile storage medium is located to perform a modeling method of a software service system according to any of claims 1-8.
11. An electronic device comprising one or more processors and a memory for storing one or more programs, wherein the one or more programs, when executed by the one or more processors, cause the one or more processors to implement the method of modeling a software service system of any of claims 1-8.
CN202310897470.1A 2023-07-20 2023-07-20 Modeling method and device of software service system, storage medium and electronic equipment Pending CN116880803A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310897470.1A CN116880803A (en) 2023-07-20 2023-07-20 Modeling method and device of software service system, storage medium and electronic equipment

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310897470.1A CN116880803A (en) 2023-07-20 2023-07-20 Modeling method and device of software service system, storage medium and electronic equipment

Publications (1)

Publication Number Publication Date
CN116880803A true CN116880803A (en) 2023-10-13

Family

ID=88254700

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310897470.1A Pending CN116880803A (en) 2023-07-20 2023-07-20 Modeling method and device of software service system, storage medium and electronic equipment

Country Status (1)

Country Link
CN (1) CN116880803A (en)

Similar Documents

Publication Publication Date Title
CN103577168A (en) Test case creation system and method
CN110968437A (en) Method, device, equipment and medium for parallel execution of single contract based on Java intelligent contract
CN114218568B (en) Big data attack processing method and system applied to cloud service
US11580012B2 (en) Smart test case generator
CN110990274A (en) Data processing method, device and system for generating test case
CN111260336A (en) Business checking method, device and equipment based on rule engine
CN105630656A (en) Log model based system robustness analysis method and apparatus
CN114048129A (en) Automatic testing method, device, equipment and system for software function change
CN115599359A (en) Code generation method, device, equipment and medium
CN115061924A (en) Automatic test case generation method and generation device
CN116661758B (en) Method, device, electronic equipment and medium for optimizing log framework configuration
CN117495544A (en) Sandbox-based wind control evaluation method, sandbox-based wind control evaluation system, sandbox-based wind control evaluation terminal and storage medium
CN111459474B (en) Templated data processing method and device
CN113051262A (en) Data quality inspection method, device, equipment and storage medium
CN109597706B (en) Detection method, device and system for checking difference data
CN116880803A (en) Modeling method and device of software service system, storage medium and electronic equipment
CN111784521B (en) Data processing method, device, equipment and system based on cash flow test
CN115033434A (en) Kernel performance theoretical value calculation method and device and storage medium
CN110659501A (en) Vulnerability processing tracking method and device, computer system and readable storage medium
CN111090638A (en) Method and device for comparing transaction functions in database migration
Saifan et al. Using formal methods for test case generation according to transition-based coverage criteria
CN113778880B (en) Intelligent contract function verification method and device based on formal verification
CN113590488B (en) System test method and test platform for simulating financial data support
CN116340127A (en) Interface testing method and device
CN117971679A (en) Intelligent contract test data generation method, device, equipment and storage medium

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination