System and method for modeling arbitrary software logic

Abstract

According to some embodiments, an arbitrary software logic modeling ("ASLM") data source can store electronic records associated with a unit, each electronic record including a unit identifier, one or more identification tags, context data, unit parameters, unit variables, and internal logic. The ASLM platform can express system requirements at the logic block level, and establish logic blocks as self-contained entities and connections based on the system requirements (the established logic blocks use graphics to represent system logic). The ASLM platform can then automatically and explicitly convert the system logic to output language-independent public design information exchange model information. The ASLM platform can also convert and maintain traceability between system requirements, public design information exchange model information, and generated code.

Description

Background Art

[0001] In software design, software source code such as functions, programs or routines is often used to implement functionality. This is true for both programming and object-oriented design, however, in the latter, these are often referred to as "methods". As used herein, these entities are collectively referred to as "functions". Functions can be used, for example, to implement low-level functionality as simple as a single mathematical operation and high-level functionality that controls components of a large system. As used herein, the term "unit" can refer to a software unit similar to a function. Note that units are not necessarily based on source code, but may instead be based on models to represent partitions of functionality of a similar range. The process of manually modeling the internal logic (e.g., algorithms) of any given arbitrary structure of a single unit and / or a large number of units may be a time-consuming, error-prone and expensive task. In addition, it may be difficult to keep track of high-level and low-level requirements and how those requirements are mapped to various functions and / or units. Therefore, there are significant difficulties and associated costs in maintaining, gradually improving, enhancing, converting and re-innovating complex, long-term systems (e.g., such as safety-critical avionics and ground system software).

[0002] It is noted that no single existing model-based design system can effectively address these problems and challenges. In general, model-based design tools fall into two major categories: 1) tools for reactive systems (such as real-time control systems) and 2) tools for conventional systems. Tools for reactive systems target specific types of applications. They tend to have extremely constrained and limited modeling constructs, and thus, may not be suitable for complex interactive information systems. Tools for conventional systems are generally capable of handling interactive systems, but their design principles generally focus on object-oriented design. Therefore, tools for conventional systems lack the ability to fully, efficiently and effectively support complex, long-term safety-critical systems. It is noted that complex, long-term safety-critical systems may have the following characteristics: strict certification requirements and deformations released during the entire life of the production line, which still need to be maintained many years after the initial release. There is no ability to build a bridge for the accumulation and accumulation of knowledge from the past in complex, long-term safety-critical systems and the revolutionary re-innovation of future products in the next few years. Activity diagrams, as often used in modeling based on the Unified Modeling Language ("UML"), are only useful when designing new software systems from scratch using highly decentralized categories, and may not help for existing arbitrary logic.

[0003] Therefore, it would be desirable to facilitate modeling of arbitrary software logic in an automated and accurate manner. Summary of the invention

[0004] According to some embodiments, an arbitrary software logic modeling ("ASLM") data source can store electronic records associated with a unit, each electronic record including a unit identifier, one or more identification tags, context data, unit parameters, unit variables, and internal logic. The ASLM platform can express system requirements at the logic block level, and establish logic blocks as self-contained entities and connections based on the system requirements (the established logic blocks use graphics to represent system logic). The ASLM platform can then automatically and explicitly transform the system logic to output language-agnostic public design information exchange model information. The ASLM platform can also transform and maintain traceability between system requirements, public design information exchange model information, and generated code.

[0005] Some embodiments include: a component for accessing an ASLM data source that stores electronic records associated with a unit, each electronic record including a unit identifier, one or more identification tags, context data, unit parameters, unit variables, and internal logic; a component for expressing system requirements at a logic block level via a computer processor of an ASLM platform; a component for establishing logic blocks as self-contained entities and connections based on system requirements, the established logic blocks graphically representing system logic; a component for automatically and explicitly converting system logic to output language-independent common design information exchange model information; and a component for converting and maintaining traceability between system requirements, common design information exchange model information, and generated code.

[0006] Some technical advantages of some embodiments disclosed herein are improved systems and methods that facilitate modeling of arbitrary software logic in an automated and accurate manner.

[0007] The present invention provides a set of technical solutions, as follows:

[0008] 1. A system for facilitating arbitrary software modeling logic ("ASLM") processing, comprising:

[0009] an ASLM data source that stores electronic records associated with a unit, each electronic record including a unit identifier, one or more identification tags, contextual data, unit parameters, unit variables, and internal logic; and

[0010] An ASLM platform, coupled to the ASLM data source, includes a computer, the computer being programmed to:

[0011] (i) express system requirements at the logical block level;

[0012] (ii) establishing said logic blocks as self-contained entities and connections according to system requirements, said established logic blocks graphically representing system logic;

[0013] (iii) automatically and explicitly transforming the system logic to output language-independent common design information exchange model information; and,

[0014] (iv) transform and maintain traceability between the system requirements, the common design information exchange model information, and the generated code.

[0015] 2. The system according to technical solution 1, wherein the system requirements include at least one of low-level requirements and high-level requirements, and the unit parameters define external unit interfaces and tracking of the ontology to allow automatic conversion of software component interfaces.

[0016] 3. The system according to technical solution 1, wherein at least one electronic record in the ASLM data source represents a block entity, and the block entity includes a block identifier, one or more identification tags, arguments, block parameters, block variables, and actions.

[0017] 4. The system according to technical solution 1, wherein the system logic includes at least one of the following items: a control node, a loop node, a merge node, an entry node, an exit node, and a null node.

[0018] 5. According to the system of technical solution 1, the ASLM platform will further run an expansion process.

[0019] 6. According to the system of technical solution 5, the expansion process includes:

[0020] Promote the parent block variable of the parent block entity to the unit variable;

[0021] Remapping of arguments for block entities and control nodes in nested sub-logics;

[0022] Merge the entry and exit nodes of the nested sub-logic with the control nodes in the unit's internal logic;

[0023] Unregister the mapping of parent block identification tags from high to low traceability;

[0024] Unregistering the parent block identifier from the data dictionary; and

[0025] Releases the parent block entity.

[0026] 7. According to the system of technical solution 1, the ASLM platform will further run an abstraction process.

[0027] 8. According to the system of technical solution 7, the abstraction process includes:

[0028] identifying subsections of logic to be abstracted;

[0029] Create a new block entity and register the block identifier in the data dictionary;

[0030] The subsection of nested logic as the action of the new block entity;

[0031] physically connecting the nested block to the location where the subsection of logic was originally connected;

[0032] establishing arguments for the nested block entity;

[0033] establishing block parameters for the nested block entity;

[0034] Creating a block variable for the nested block entity; and

[0035] An identification tag is established for the nested block entity, and the block entity is registered in a high-to-low traceability mapping.

[0036] 9. According to the system of technical solution 1, wherein the ASLM platform will further run a splitting process.

[0037] 10. According to the system of technical solution 9, the splitting process includes:

[0038] Make nested block entities abstract for splitting into new units;

[0039] Create a new unit and register the unit identifier in the data dictionary;

[0040] establishing unit parameters for the new unit;

[0041] Establishing a unit variable for the new unit;

[0042] transferring the nested sub-logic of the nested block entity to the new unit;

[0043] Generalizing the block entities and control nodes encapsulated in the new unit;

[0044] Creating an identification tag for the new unit and registering the new unit in a high-to-low traceability map;

[0045] Updating the nested block entity by referencing the new unit;

[0046] The identification tag of the nested block entity is updated, and the block entity in the high-to-low traceability map is updated, and the updating process is repeated for the original unit.

[0047] 11. According to the system of technical solution 1, the ASLM platform will further run a merging process.

[0048] 12. According to the system of technical solution 11, the merging process includes:

[0049] identifying a block entity in a cell that references the combination of cells to be merged;

[0050] Expanding the block variables of the parent block entity to include the cell variables from the cell to be merged;

[0051] Transferring the internal logic of the unit to be merged to the nested sub-logic of the parent block entity;

[0052] remapping arguments for block entities and control nodes incorporated into the nested sub-logic;

[0053] updating the identification tag of the nested parent block entity and updating the registration of the parent block identifier in the high-to-low traceability mapping, and repeating the updating process for the combined unit;

[0054] deregistering the identification tag of the unit to be merged from the high-to-low traceability mapping;

[0055] deregistering the unit identifier of the unit to be merged from the data dictionary; and

[0056] The unit that has been merged into the combined unit is released.

[0057] 13. A computerized method for facilitating arbitrary software modeling logic ("ASLM") processing, comprising:

[0058] accessing an ASLM data source that stores electronic records associated with a unit, each electronic record including a unit identifier, one or more identification tags, context data, unit parameters, unit variables, and internal logic;

[0059] Expressing system requirements at the logic block level via a computer processor of an ASLM platform;

[0060] Establishing said logic blocks as self-contained entities and connections according to said system requirements, said established logic blocks graphically representing system logic;

[0061] Automatically and explicitly converting the system logic to output language-independent common design information exchange model information; and

[0062] The system requirements, common design information exchange model information, and traceability between generated code are converted and maintained.

[0063] 14. The method according to technical solution 13, wherein the system requirements include at least one of low-level requirements and high-level requirements.

[0064] 15. The method according to technical solution 13, wherein at least one electronic record in the ASLM data source represents a block entity, and the block entity includes a block identifier, one or more identification tags, arguments, block parameters, block variables, and actions.

[0065] 16. The method according to technical solution 13, wherein the system logic includes at least one of the following items: a control node, a loop node, a merge node, an entry node, an exit node, and a null node.

[0066] 17. According to the method of technical solution 13, the ASLM platform will further run at least one of the following items: an expansion process, an abstraction process, a splitting process, and a merging process.

[0067] 18. A non-transitory computer readable medium storing instructions that, when executed by a computer processor, cause the computer processor to perform a method for facilitating arbitrary software modeling logic ("ASLM") processing, the method comprising:

[0068] accessing an ASLM data source that stores electronic records associated with a unit, each electronic record including a unit identifier, one or more identification tags, context data, unit parameters, unit variables, and internal logic;

[0069] Expressing system requirements at the logic block level via a computer processor of an ASLM platform;

[0070] Establishing said logic blocks as self-contained entities and connections according to said system requirements, said established logic blocks graphically representing system logic;

[0071] Automatically and explicitly converting the system logic to output language-independent common design information exchange model information; and

[0072] The system requirements, common design information exchange model information, and traceability between generated code are converted and maintained.

[0073] 19. The medium according to technical solution 18, wherein the system requirement includes at least one of a low-level requirement and a high-level requirement.

[0074] 20. The medium according to technical solution 18, wherein at least one electronic record in the ASLM data source represents a block entity, and the block entity includes a block identifier, one or more identification tags, arguments, block parameters, block variables, and actions.

[0075] 21. The medium according to technical solution 18, wherein the system logic includes at least one of the following items: a control node, a loop node, a merge node, an entry node, an exit node, and a null node.

[0076] 22. According to the medium of technical solution 18, the ASLM platform will further run at least one of the following items: an expansion process, an abstraction process, a splitting process, and a merging process. BRIEF DESCRIPTION OF THE DRAWINGS

[0077] Figure 1 is a high-level block diagram of a system that may be provided in accordance with some embodiments.

[0078] Figure 2 is a method that facilitates modeling of arbitrary software logic according to some embodiments.

[0079] Figure 3 A unit according to some embodiments is shown.

[0080] Figure 4 Illustrated is a block entity according to some embodiments.

[0081] Figure 5 are control nodes and control flow networks according to some embodiments.

[0082] Figure 6 is an example of issuing a security pass according to some embodiments.

[0083] Figure 7 is an internal logic model according to some embodiments.

[0084] Figure 8 Illustrated is issuing a security pass with nested logic according to some embodiments.

[0085] Fig. 9 is an example of extension and abstraction for nested block entities according to some embodiments.

[0086] Fig.10 is a method for expanding a nested block entity according to some embodiments.

[0087] Fig.11is a method for abstracting nested block entities according to some embodiments.

[0088] Fig.12 is an example of splitting and merging cells according to some embodiments.

[0089] Fig.13 is a method for splitting a cell according to some embodiments.

[0090] Fig.14 is a method for merging cells according to some embodiments.

[0091] Fig.15 is a chained model unit process according to some embodiments.

[0092] Fig.16 is a block diagram of a device or platform according to some embodiments.

[0093] Fig.17 is the tabular portion of any software logic modeling database according to some embodiments.

[0094] Fig.18 is a display according to some embodiments. DETAILED DESCRIPTION

[0095] In the detailed description below, many specific details are set forth to provide a thorough understanding of the embodiments. However, it will be appreciated by those skilled in the art that the embodiments may be practiced without these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail to avoid obscuring the embodiments.

[0096] Figure 1 is a high-level architecture of a system 100 according to some embodiments. The system 100 includes an arbitrary software logical modeling ("ASLM") data source 110 that provides information to an ASLM platform 150. The data in the ASLM data source 110 may include, for example, information about software components, applications, high-level requirements ("HLR") documents, low-level requirements ("LLR") documents, software code, etc.

[0097] According to some embodiments, the ASLM platform 150 can access the ASLM data source 110 and facilitate the creation and / or manipulation of software elements. According to some embodiments, the graphical user interface ("GUI") 155 of the ASLM platform 150 can interact with the remote user device 170 to automatically perform operations on these software components. As used herein, the term "automatically" can refer to, for example, an action that can be performed with little human intervention.

[0098] As used herein, devices (including devices associated with system 100 and any other devices described herein) can exchange information via any communication network that can be one or more of the following communication networks: a local area network ("LAN"), a metropolitan area network ("MAN"), a wide area network ("WAN"), a proprietary network, a public switched telephone network ("PSTN"), a wireless application protocol ("WAP") network, a Bluetooth network, a wireless LAN network, and / or an Internet Protocol ("IP") network such as the Internet, an intranet, or an extranet. Note that any device described herein can communicate via one or more such communication networks.

[0099] The ASLM platform 150 can store information in and / or retrieve information from various data sources, such as the computer ASLM data source 110 and / or the user platform 170. The various data sources can be stored locally or exist in a location remote from the ASLM platform 150. Figure 1 A single ASLM platform 150 is shown in the figure, but any number of such devices may be included. In addition, the various devices described herein may be combined according to embodiments of the present invention. For example, in some embodiments, the ASLM platform 150 and one or more data sources may comprise a single device. The functions of the ASLM platform 150 may be performed by a group of networked devices (such as those associated with a cloud-based or distributed processing architecture).

[0100] The elements of system 100 may be operated to implement any of the embodiments described herein. For example, Figure 2 Diagrams facilitate the modeling of arbitrary software logic, which can be done by Figure 1 Some or all of the elements of the described system 100 perform arbitrary software logic modeling. The flowcharts described herein are not intended to be a fixed order for the steps, and embodiments of the present invention may be practiced in any order that is feasible. Note that any method described herein may be performed by hardware, software, manually through a GUI, or any combination of these approaches. For example, a computer-readable storage medium may store instructions thereon that, when run by a machine, cause the performance of any embodiment described herein.

[0101] At S210, the ASLM platform may access an ASLM data source that stores electronic records associated with a unit, each electronic record including a unit identifier, one or more identification tags, context data, unit parameters, unit variables, and internal logic. According to some embodiments, at least one electronic record in the ASLM data source may represent a block entity, and the block entity includes a block identifier, one or more identification tags, variables, block parameters, block variables, and actions. According to some embodiments, the ASLM data source may neither store all of the information elements described herein nor fully store all of the units of a system component or a complete system.

[0102] At S220, the system may express system requirements at the logic block level via a computer processor of the ASLM platform. The system requirements may represent, for example, low-level requirements ("LLRs") and / or high-level requirements ("HLRs"). At S230, the system may establish logic blocks as self-contained entities and connections according to the system requirements, and the established logic blocks represent system logic with a graph. As used herein, the phrase "system logic" may be associated with, for example, control nodes, loop nodes, merge nodes, entry nodes, exit nodes, and / or empty nodes.

[0103] At S240, the system can automatically and explicitly transform the system logic to output language-independent Common Design Information Interchange Model ("CDIM") information. For example, the CDIM standard can be used to provide common design information about components or functional elements associated with the tracked ontology, the tracked HLR, data types, variables, and / or interfaces. At S250, the system can convert and maintain traceability between system requirements, common design information exchange model information, and generated code.

[0104] Thus, some embodiments described herein can provide methods and computer program tools to model arbitrary software logic within a single programming unit and / or across multiple programming units using block entities. Block entities are basic software building blocks that are intended to implement one or more actions to meet the purpose assigned in the software. At least one block entity can be defined to: implement one or more actions, express at least one first aspect of a low-level requirement or multiple low-level requirements, maintain traceability of higher-level requirements, and provide interfaces for interaction with other block entities. A block entity or multiple block entities can be connected through a control flow network to: control the actions among the block entities, express at least one second aspect of a low-level requirement or multiple low-level requirements. In addition, traceability of higher-level requirements and software testing can be maintained to form software logic of any given arbitrary structure for one unit or a large number of units. Then, software code can be generated from the model in the selected programming language.

[0105] Some embodiments described herein may be used with Figure 3 Note that, in addition to any conventional elements that may be used for a particular application (such as those not shown in Figure 3 In addition to the notes shown in Figure 3 Also shown are some basic elements that can make up the units.All basic elements can be identified following the naming conventions specified under defined software design standards, which are specific to the problem domain or as a general standard for tools.

[0106] The unit identifier 310 can represent a descriptive name for explicitly identifying the intended functionality of the unit 300. As long as the unit identifier 310 for the unit is unique within the scope of the architectural element that encapsulates the current unit, it does not have to be globally unique. The defined software design standards can impose additional requirements on identifier uniqueness. One or more identification tags 320 can explicitly maintain the traceability of the unit identifier 310 and the unit 300 itself to higher-level requirements (including derived requirements). The identification tag 320 can be globally unique, or unique within the scope of the level of the requirement it tracks (if so specified in the defined software design standards). The unit 300 can also include context data 330, which is used to explicitly specify dependencies on entities external to the unit. The context data can also include data members or variables or global variables of the category or package to which the unit belongs, etc.

[0107] Unit 300 may also include unit parameters 332, which are used to represent formal data items that are expected to be received and output by unit 300. Note that unit parameters 332 may be similar to parameters defined for functions. Unit parameters 332 may define external unit interfaces. Thus, individual parameters of unit parameters 332 may be tracked to the ontology (not shown) in a similar manner to the way in which identification tags 320 are used to explicitly maintain the traceability of unit identifiers 310 to higher-level requirements. For software units exposed as external interfaces of software components, the traceability of unit parameters to the ontology may be important. While maintaining readability (for humans), interface completeness, and software integrity, this traceability may allow the conversion of software component interfaces (e.g., automatically). Unit variables 334 (including any associated unit declarations) may represent variables intended only for use within unit 300. Unit variables 334 may be similar to unit parameters 332 in this respect: they may be accessible at any position within unit 300. The unit 300 may also include internal logic 340, which represents specific functionality intended to be performed by the unit 300. The internal logic 340 may be represented by a control flow network connecting the block entities of the unit 300.

[0108] A unit identifier 310, one or more identification tags 320, and internal logic 340 may represent the required elements of a unit 300. A unit 300 that does not have explicit context data 330 may have an implicit "empty" context. The same may be true for unit parameters 332 and unit variables 334. If source code is used as the master archive, language features may be used according to design standards to represent the definition of a unit 300 and its elements.

[0109] Some embodiments described herein may be used with Figure 4 In addition to any conventional elements that can be used for a specific application (such as those not shown in Figure 4 In addition to the notes shown in Figure 4 Also shown are the basic elements that can make up a block entity.All basic elements can be identified following the naming conventions specified under a defined software design standard, which can be specific to a problem domain or as a general standard for tools.

[0110] The block entity 400 may include a block identifier 410, which is a descriptive name used to explicitly identify the intended functionality of the block entity 400. The block identifier 410 for a block unit may not need to be globally unique as long as it is unique within the scope of the architectural element that encapsulates the current unit. This means that, typically, uniqueness within the current unit is insufficient. Defined software design standards may impose additional requirements on identifier uniqueness.

[0111] Block entity 400 can include one or more identification tags 420, and identification tags 420 are used to explicitly maintain the traceability of block identifier 410 and block entity 400 itself to higher-level requirements (including derived requirements). Conceptually, the identification tag 420 for a block may not be different from the identification tag for a unit. Block variables 430 can be used to represent the specific data items that are transferred to and from block entity 400. The specific data items are essentially selected items from unit context, unit parameters and unit variables to meet the needs of block entity 400. Variables 430 can be input, output or input and output at the same time. Block parameters 432 can be used to represent the formal data items that are expected to be received and output by block entity 400. Block parameters 432 can be similar to parameters defined for functions. The purpose of using the combination of block variables 430 and block parameters 432 can be to isolate block actions 440 from environmental contexts so that the implementation scheme of actions can be more generalized. This generalization can allow automated model conversion. In source code (written manually or generated from a model), model parameters 432 can be implicitly embedded in block actions. Note that a mapping can be established between block arguments 430 and parameters 432. Multiple parameters 432 can be mapped to (implemented by) a single argument 430, but only a single argument 430 can be mapped to (implement) a single parameter 432. That is, multiple arguments 430 cannot be mapped to a single parameter 432. Block variables 434 (including any associated block declarations) represent variables that are intended only for use within the scope of the block entity 400, regardless of the actual location of the declaration of the variable in the unit.

[0112] Action 440 represents functionality intended to be implemented by block entity 400. According to some embodiments, conventional block entity 400 cannot have only decision control action 440 (except for block entity acting as a node in control flow network). Any decision control action 440 in conventional block entity 400 must be accompanied by non-decision control action, wherein the non-decision control action is controlled by decision control action 440. Action 440 can be expressed in terms of block parameters 432 and block variables 434. Data exchange can be implemented using only block parameters 432. Note that external data items such as unit parameters and unit variables may not be visible to block action 440. Block entity 400 that does not have explicit elements of any given kind has implicit empty elements of the same kind (except for block identifier 410 that must be provided and identification tag 420 that must provide at least one). If source code is used as a master file, language features can be used according to design standards to represent the boundaries and block elements of block entity 400. Note that, by definition, block entity 400 cannot be a unit, and vice versa. Even if the elements are implicit, a block entity 400 may always have an element of the kind of argument 430, while a cell may not have any arguments.

[0113] Figure 5 Diagram 500 shows a control node (including node identifier 510, identification tag 520, argument 530, node parameter 532, node variable 534, and decision control action 540) and a control flow network according to some embodiments. In addition to conventional block entities (not shown) and any conventional elements such as annotations (not shown) that can be used for specific applications, Figure 5 Also shown are the basic elements that can make up the control flow network itself. All basic elements can be identified following the naming convention specified under the defined software design standards, wherein the defined software design standards are specific to the problem domain or as a general standard for tools. The control flow network exists within a unit. The control flow network can be exposed to the unit context, unit parameters and unit variables. This means that the unit context, unit parameters and unit variables are visible by the entities within the control flow network. Note that the control flow network can contain a directional graph, wherein each edge has a conventional block entity, and each node controls the operation of the downstream block entity. The nodes in the control flow network can be regarded as special kinds of block entities. Thus, the node contains all the elements that make up the block entity. The same uniqueness requirements for the block entity apply to the nodes in the control flow network. The difference between the nodes in the control flow network and the conventional block entity is the action element. The node can have only decision control actions, while the conventional block entity cannot have only decision control actions.

[0114] The control flow network has a single entry node 550 and a single exit node 590. The embodiment described herein based on this definition allows the use of efficient automation in the model conversion across the unit boundary. This definition is for the purpose of software logic modeling, and this definition does not limit the implementation of the software in the actual source code, target code or executable target code to a single entry point and a single exit point, even if the software design standard defined may impose such requirements or guidance. The entry node 550 is a node of a special kind of control that its only action will start the control of the unit. The exit node 590 is a node of a special kind of control that its only action will end the control of the unit. According to the definition, the statement in the function that returns the output parameter to the caller cannot be included in the exit node 590 as a whole. The parameter return functionality may be included as the part of the action element of the conventional block entity instead. The action that is only used to end the control of the unit can be included in the exit node 590 for the unit. The method allows the function with multiple return statements to be modeled as a unit with a single exit node 590.

[0115] The control node is where the edges are connected together and branch outward. Although the connection of the nodes is not necessarily controlled by the control node, the branches extending from the nodes are always controlled by the control node through its decision control actions. In addition to any traditional elements such as annotations that can be used for specific applications, not shown, Figure 5 The elements that can make up a control node are shown as diamond-shaped entities on the left. Although many different kinds of decision control actions may be available, specific applications may limit the types of decision control actions that can be used according to rules specified under defined software design standards. Each control node can have only one decision action. Figure 5 In the embodiment shown in , three control nodes 560, 570, 580 are depicted. Control node A 560 depicts a decision control action similar to a selection control structure. Control node B 570 depicts an iterative control structure. Control node C 580 depicts a dedicated merge node with an implicit decision control action; that is, there is only one branch extending from the control node, so no explicit decision control action is required. Other decision control actions may include, but are not limited to, switch control structures. In the case of parallelized branches, multiple branches may be selected by the same control node. Note that the control structure must be closed by a merge node. This can be satisfied by a dedicated merge node (such as, control node C 580) or by a loop control node itself (such as, control node B 570). The local variables of the control node remain within the scope along its designated branch until the control structure is closed. Note that the control flow network can allow direct analysis of the complexity of the unit. Various control structure-based complexity metrics can be calculated.

[0116] To describe a method for modeling arbitrary software logic, consider Figure 6 A sample problem regarding issuing security passes is illustrated in the process 600 shown in FIG. 2 . It can be assumed that there are two scenarios: 1) issuing security passes for individuals, and 2) issuing security passes for groups. In addition, individuals can be classified as "general" individuals or "special" individuals (e.g., the permissions for special individuals may be limited). Note that the security passes are not issued in the example. Figure 6 The distinction between general individuals and special individuals is clearly shown in . It is further assumed that the security pass has features for identifying whether an individual belongs to a group and for simplifying security management, and individuals within the group are not distinguished according to their own classification. For example, all members of the group are considered to have a special classification. After starting at 610, process 600 determines whether an individual or group workflow should be started at 620. If the individual workflow is appropriate, then at 630, a pass is issued, and, at 690, the process ends. Before ending 690, if the group workflow is appropriate, then at 640, process 600 loops through each member of the group, and at 650, a pass is issued when appropriate.

[0117] exist Figure 7 , another view of the process is illustrated, which illustrates the internal logic of the "Issue_Pass" unit 700 in terms of the low-level requirements in software design. The internal logic of the unit Issue_Pass 700 is modeled by a control flow network that connects the block entities. Note that the control flow network contains an entry node 710, an exit node 790, and three control nodes. The Select_Cat control node 720 has the following explicit elements: a label ("HLR_010"), variables, parameters, and a decision control action that selects the branch to be taken. Note that the Select_Cat control node 720 has an implicit empty node variable element (because, selection controls do not usually require local variables). Loop_Member is a loop control that can make all elements as explicit, which includes a node variable representing an iterator. Merge_3 is an implicit join (merge) control node (meaning that, except for its identifier and at least one label, all other elements are implicit). In Figure 7, the elements of Loop_Member and Merge_3 are not shown to reduce clutter. Each edge in the control flow network has a block entity, and there are six block entities in total. Issue_Ind_Pass 730 and Issue_Grp_Pass 750 have all elements as explicit. The other four block entities have implicit null action elements. These four block entities are named Null_Block_0, Null_Block_2, Null_Block_4, and Null_Block_5.

[0118] like Figure 7 As illustrated in , low-level requirements can be expressed by the required functionality, abstracted into block entities (represented by their explicit descriptive identifiers) and logical behaviors (abstracted into control flow networks), and the logical behaviors are represented by explicit descriptive identifiers for each control node and the network topology that connects the control nodes. If so desired, annotation elements can be included to provide further descriptions of each explicit descriptive identifier (but such annotations are not required). Instead, a data dictionary mechanism can be used to track identifiers, and additional descriptions of each identifier can be provided in a central database or in a distributed manner. Guided by the defined software design standards, if the functionality or behavior of an entity changes to a different scope, its explicit descriptive identifier can also be changed. In such a case, the defined software configuration management standards may require new entities to be created or derived from old entities and the old entities to be overruled.

[0119] According to some embodiments, the refinement of the action details encapsulated in each entity can reflect the implementation details. If the requirements are not affected by such implementation details, the low-level requirements expressed by the model remain the same. Thus, the granularity of the model can be consistent with the low-level requirements so as to accurately reflect the changes that affect the requirements. Taking into account, for example, the difference with the flat logical structure that is maintained at the same level with the model granularity throughout all block entities in the unit, the nested block entity can be used to maintain the consistency between the model granularity and the low-level requirements, and at the same time to improve the level of abstraction. In the nested block entity, its action element contains nested logic. The nested logic is the same as the normal logic described above. In addition to the entry node of the nested block entity being consistent with the upstream control node of the current block entity, and the exit node of the nested block entity being consistent with the downstream control node of the current block entity, the nested block entity is also modeled by connecting the control flow network of the conventional block entities. The block entities within the nested block entity can be further nested.

[0120] It should be noted that the nesting logic of the nested block entity is still part of the internal logic of the current unit. This is different from the internal logic of the function called by the block entity. The internal logic of the function called by the block entity may be considered to belong to a separate unit instead. The process of expanding the nesting logic of the nested block entity into the internal logic of the parent unit may not affect the low-level requirements expressed by the model or the architecture of the software system. Conversely, the process of abstracting the sub-parts of the internal logic of the unit and encapsulating them into the nested block entity may also not affect the low-level requirements expressed by the model or the architecture of the software system.

[0121] Note how you can use Figure 7 The traceability of higher-level requirements is maintained by the identification tag of the Issue_Pass unit 700. Specifically, the traceability of higher-level requirements can be maintained at the block entity level and the control node level. For example, the block entity Issue_Ind_Pass has two tags, HRL_011 and HLR_030, to maintain the traceability of high-level requirements 011 and 030. The block entity Issue_Grp_Pass has two tags, HLR_013 and HLR_030, to maintain the traceability of high-level requirements 013 and 030. Similarly, the control node Select_Cat has a tag, HLR_010, to maintain the traceability of high-level requirement 010. Null_Block_0, Null_Block_2, Null_Block_4, and Null_Block_5 have a tag, HLR_006, to maintain the traceability of high-level requirement 006. The idea is that block entities with implicit empty action elements are also traceable for higher-level requirements. For the purpose of simulation and testing, such block entities with implicit empty action elements will also allow model coverage and structural coverage instruments to be incorporated into the generated code. According to some embodiments, the identification tag of the unit Issue_Pass neither provides information unrelated to the identification tags of the block entities and control nodes contained in the unit, nor provides copy information. The identification tag of the unit Issue_Pass is simply a reference to all identification tags of block entities and control nodes from the unit's internal logic. The same rule can be applied to nested block entities, wherein the identification tag of the parent block entity can only contain references to all identification tags of block entities and control nodes from the nested logic.

[0122] Using this approach, extending the nested logic of a nested block entity into the internal logic of a parent unit (and thus eliminating the parent nested block entity itself) does not affect traceability to higher-level requirements, and does not require any adjustments to the traceability maintained by the block entities and control nodes in the nested logic. Conversely, the process of abstracting and encapsulating a sub-portion of the unit's internal logic into a nested block entity does not affect traceability to higher-level requirements, and does not require any adjustments to the traceability maintained by the block entities and control nodes to be encapsulated into the nested logic.

[0123] According to some embodiments, bidirectional traceability between higher-level requirements and low-level requirements and low-level designs is maintained by an index or mapping method that tracks all entities (block entities and control nodes) that implement any given higher-level requirement. This approach can use two mechanisms to maintain high-to-low traceability indexes or mappings. A "registration" mechanism can be used to achieve efficient and reliable establishment of mappings for individual entities. A "search and index" mechanism can be used to establish or refresh indexes or mappings on a periodic or event-driven basis, such as after a major system update or architecture change.

[0124] Some embodiments described herein may provide methods for extending and abstracting nested block entities. To illustrate such a feature, Figure 6 The block "Issuing a Pass for an Individual" in the software logic depicted in FIG. 1 is expanded to show how Figure 8 The nested logic depicted in process 800 of . The nested logic distinguishes individuals according to their classification, and issues security passes based on the classification. As before, after starting at 810, process 800 determines whether an individual or group workflow should be initiated at 820. If the individual workflow is appropriate, a general pass is issued at 830, 832, or a special pass is issued at 830, 834, and the process ends at 890. Before ending 890, if the group workflow is appropriate, at 840, process 800 loops through the members of the group and, at 850, issues passes when appropriate. Security passes for individuals in a group can be based on group policy, so it may not be necessary to distinguish whether individuals in a group should be treated differently based on their individual classification.

[0125] Fig. 9 The "Issue_Pass" unit 910, 920 associated with the extension process and the abstraction process is shown. As used herein, the term "extension" may refer to a model transformation that removes the abstraction and encapsulation provided by the nested block entity and merges its nested logic directly into the internal logic of the current unit (in Fig. 9Abstraction refers to the reverse process of encapsulating multiple parts of logic into new nested block entities (in Fig. 9 , from right to left, create "Issue_Ind_Pass" 912).

[0126] exist Fig.10 In, a method for expanding nested block entities is depicted. The figure shows how to handle each element of the block entity and control node in the nested sub-logic and each element of the parent block entity during the conversion. The main effect of this conversion is that after the conversion, the nested sub-logic of the parent block entity is now exposed to unit parameters and unit variables (and this may need to be properly handled). At S1002, the block variables in the parent block entity are promoted to unit variables. By modifying the names of the promoted variables, any name conflicts identified in the process are resolved. Name conflicts are possible because the block variables are assumed to be invisible outside the block. At S1004, the variables of the block entity and control nodes in the nested sub-logic are remapped to existing unit parameters and unit variables and those new unit variables promoted from the block variables of the parent block entity. By directly connecting those variables to the existing unit parameters and unit variables through the relationship initially maintained by the block parameters of the parent block entity, the mapping to the existing unit parameters and unit variables is achieved. Once the mapping is completed, the block parameters of the parent block entity are bypassed, and the block parameters of the parent block entity are no longer needed. The mapping to the new unit variable promoted from the block variable of the parent block entity is realized by only maintaining the original relationship. Note that the identification tags, block parameters, block variables, and actions or decision control actions of the block entity and control nodes in the nested sub-logic remain the same without change. Thus, while maintaining the traceability of the low-level requirements expressed in the model and the requirements of higher levels, some embodiments described herein can allow efficient automation to be used in the conversion. At S1006, the entry node of the nested sub-logic is merged with the closest upstream control node of the parent block entity. The exit node of the nested sub-logic is merged with the closest downstream control node of the parent block entity. Since the entry node and exit node of the nested sub-logic are essentially virtual control nodes, the merger is realized by only connecting the nested sub-logic to the internal logic of the unit. At S1008, the mapping of the traceability of the identification tag of the parent block entity from high to low requirements is cancelled. Since the traceability is maintained at the block entity control node level, this step does not affect the traceability. At S1010, if a data dictionary is used to track the block identifier, the parent block identifier is cancelled from the data dictionary. Since the functionality represented by the nested sub-logic becomes a direct part of the internal logic of the unit, the block identifier of the parent block entity is no longer needed. At S1012, the parent block entity may be released.

[0127] exist Fig.11 , depicting a method for abstracting nested block entities, Fig.11 It shows how to handle the elements of the new nested block entity and the sub-segment of the unit internal logic to be converted into the nested sub-logic during the conversion. At S1102, the sub-segment of the unit internal logic is identified for abstraction. This is essentially a dedicated decision. The sub-segment of the logic is required to have a unique incoming connection and a unique outgoing connection to the rest of the control flow network. The incoming edge and the outgoing edge should be included as part of the sub-segment. At S1104, a new block entity is created. An explicit descriptive block identifier is created based on the expected functionality to be nested in the new block entity. The new block entity will serve as an abstraction of the functionality to be nested. If a data dictionary is used to track block identifiers, the new block identifier is registered in the data dictionary. At S1106, the identified sub-segment of the unit internal logic is nested in the new block entity as its action. The starting point of the incoming edge and the end point of the outgoing edge of the sub-segment of the logic become the entry node and exit node of the nested sub-logic respectively. Note that the identification tags, block parameters, block variables, and actions or decision control actions of the block entities and control nodes in the nested sub-logic remain the same, and thus do not need to be changed. Thus, while maintaining the traceability of the low-level requirements expressed in the model and the requirements of higher levels, some embodiments described herein can allow efficient automation to be used in the conversion. At S1108, the nested block entity is connected to the closest upstream control node and the closest downstream control node, wherein the nested sub-logic is initially connected to the remainder of the internal logic of the unit. At S1110, the variables of the nested block entity are established by aggregating the variables of the block entities and control nodes in the nested sub-logic. At S1112, the block parameters of the nested block entity are established by a direct one-to-one mapping of the variables established in the previous step. This can help keep the interface of the nested sub-logic unchanged during the conversion. At S1114, the unit variables that are only intended to be used for the nested sub-logic and thus only referenced by the nested sub-logic are downgraded to the block variables of the nested block. Since the block arguments and block variable entities of the nested blocks corresponding to the downgraded block variables no longer meet any purpose, they are removed. In addition, the post-conversion design activity can be started to further adjust or modify the nested block entity. As a temporary conversion for trying different abstraction options, or if desired, during this process, the unit block variable downgrade step can be skipped. The same effect can be achieved by using a dedicated post-conversion unit variable that downgrades the process. At S1116, the identification tag of the nested block entity can be established by referencing the identification tags of the block entities and control nodes in the nested sub-logic. The nested block entity is registered in the mapping of the traceability of the high to low requirements for each tracked requirement to ensure the latest two-way traceability for the most recently created nested block entity.

[0128] Note that abstraction can also be applied to control nodes to model any arbitrary control structure (including those control structures not supported by existing programming languages). In this case, the action elements of the nested control nodes are no longer limited to control decision actions. Complex control decision logic involving the use of actions other than decision control actions can be used.

[0129] Fig.12 An "Issue_Pass" unit 1210, 1220 is illustrated in association with a split process and a merge process. Note that the same approach used to model a single unit as separate processes in a parallel or sequential manner can be used to model multiple separate individual units. Fig.12 1222). As used herein, the term "split" may refer to a model transformation that divides a single unit into two or more units (from left to right, as in Fig.12 The term "merge" may refer to the reverse process of combining two or more units into a single unit (as shown in Fig.12 , from right to left). By definition, these processes may cause architectural changes. Recently created units may become accessible outside the original unit. Old units combined into a combined unit may no longer be accessible from outside the combined unit. Splitting and merging can be achieved by additional steps built on the method for making nested block entities extensible and abstract.

[0130] exist Fig.13 , describing the method of splitting the unit, Fig.13It shows how to handle each unit element of the new unit split from the original unit during the conversion. At S1302, if there is no nested block entity for the sub-section of the logic to be split into the new unit, the nested block entity is abstracted in the original unit following the method for abstraction described earlier. At S1304, a new unit is created. An explicit descriptive unit identifier is created based on the expected functionality to be encapsulated in the new unit. The unit identifier is a more generalized derivative of the nested block entity identifier, in which the environmental context of the nested block identifier should be de-identified. For example, if the block identifier of the nested block entity is Calculate_Area_of_Window, the unit identifier can be Calculate_Area_of_Rect, which means that the unit can be used to calculate the area of ​​any planar object that is rectangular in shape. If the intention of the conversion is to reuse the sub-logic as a whole to support multiple units, only generalization is required. If a data dictionary is used to track unit identifiers, the new unit identifier is registered in the data dictionary. At S1306, the unit parameters of the new unit are established by filling the block parameters of the nested block entity. At S1308, the unit variables of the new unit are established by filling the block variable entity of the nested block. At S1310, the nested sub-logic of the nested block entity is transferred to the new unit as its internal logic. The entry node and exit node of the nested sub-logic of the nested block entity become the entry node and exit node of the new unit. At S1312, the identification label is remapped for the block entity and control node in the transferred internal logic of the new unit, and the block identifier is generalized. If the intention of the conversion is to reuse the sub-logic as a whole to support multiple units, only generalization and remapping are required. If this is indeed the case, the purpose of generalization and remapping is to remove references to higher-level requirements specific to the de-identified environmental context. If each of the block entities and control nodes in the original nested sub-logic has been generalized by fully utilizing block variables and block parameters to isolate the block action from the environmental context, the current step becomes unnecessary (this may be standard practice). Thus, while maintaining the low-level requirements expressed in the model and traceability to higher-level requirements, some embodiments described herein can allow efficient automation to be used in the conversion. Note that the block entities and block parameters, block variables, and actions or decision control actions of the control nodes in the transferred internal logic of the new unit can remain the same and do not need to be changed. However, post-conversion design activities can be initiated to adjust or modify the naming of these elements, along with any other desired changes. If human intervention is required in this step, the relevant elements can be automatically annotated to ensure consistent actions are taken.At S1314, an identification tag of a new unit is established by referencing the identification tags of block entities and control nodes in the internal logic. For each traced requirement, the unit is registered in the mapping of traceability of high to low requirements to establish bidirectional traceability for the most recently created unit. At S1316, the block variable entities of the nested blocks in the original unit are removed because they are no longer needed. The actions of the nested block entities are replaced with references to the new unit. The variables of the nested block entities remain the same. At S1318, the identification tag of the nested block entity is updated to reflect the authorization of the functionality encapsulated in the new unit. At the same time, the identification tag of the original unit is updated to reflect the authorization of the functionality encapsulated in the new unit. Specifically, only environmental context specific requirements are maintained. The entries of the nested block entity in the mapping of traceability of high to low requirements are updated.

[0131] exist Fig.14 , depicting a method for merging cells, Fig.14How to make a unit be combined into another unit as a nested block entity in another unit is shown. The first unit is called the unit to be merged, and the second unit is called the combined unit. If direct one-to-one merging does not meet the modeling needs, the necessary steps of encapsulating any merging by using one-to-one merging, together with splitting the parent unit to create a new combined unit, can always achieve any merging. At S1402, the block entity in the combined unit that references the unit to be merged is identified. The block entity is called the parent block entity. After the conversion steps described below, the block entity becomes a nested block entity. If the unit to be merged is referenced by multiple block entities, the method can be applied to each such block entity, each parent block entity. At S1404, the block variables of the parent block entity are expanded to include the unit variables from the unit to be merged. By modifying the name of the merged unit variable, any name conflict identified in the process is resolved. Since it is assumed that the block variables and unit variables are not visible outside these entities themselves, name conflicts are possible. At S1406, the internal logic of the unit to be merged is transferred to the parent block entity in the combined unit, as a nested sub-logic. This is achieved by replacing the reference to the unit to be merged with the internal logic of the unit. Make the entry node and exit node connected to the nested sub-logic of the most recent combination. At S1408, the variables of the block entity and control node in the nested sub-logic are remapped to the existing block parameters and block variables of the parent block entity. This mapping is achieved by initially passing the variables of the unit to be merged before merging and by any adjustments made during the resolution of the block variable name conflict. The block parameters, block variables and actions or control decision actions of the block entity and control node in the nested sub-logic remain the same, because they have been isolated from the environmental context by means of their variables. The low-level requirements and low-level designs expressed by the block entity and control node merged into the parent block entity also remain the same. At S1410, the identification tag of the nested parent block entity is updated to include the reference to the identification tag of the block entity and control node merged into the nested sub-logic. The identification tag of the nested parent block entity now includes traceability for both context specific requirements and requirements previously handled by the unit and now merged into the nested block entity. In the mapping of traceability of high to low requirements, the registration of the parent block identifier is updated to maintain the integrity of the bidirectional traceability. At the same time, the identification tag and registration of the merged unit are also updated. At S1412, if all identified parent block entities in the combined unit and any other unit are converted following the steps above, the identification tag of the unit to be merged is deregistered from the mapping of traceability of high to low requirements. At S1414, if a data dictionary is used to track unit identifiers, the unit identifier of the unit to be merged is deregistered from the data dictionary.Since the functionality represented by the unit to be merged becomes part of the nested parent block entity in the internal logic of the combined unit, the unit identifier of the unit to be merged is no longer needed. At S1416, the unit merged into the combined unit can be released. Through these steps, the unit to be merged is converted into part of the nested sub-logic of the nested parent block entity. If desired, the nested parent block entity can be further expanded according to the method described earlier to serve as a direct part of the internal logic of the combined unit. For a specific parent block entity, only a part of the logical flow network in the unit to be merged (the first unit) may have been traversed. Thus, steps S1404, S1406 and S1408 may only involve those items related to the part of the logical flow network in the first unit. A software design decision may be to merge the unit into some parent block entities, but not into other parent block entities. Thus, since the unit merged into some block entities is still referenced by some other block entities, steps S1412, S1414, and S1416 can be skipped.

[0132] exist Fig.15 In FIG, a chain of model unit transformation processes is illustrated by methods for expansion, abstraction, splitting, and merging. In particular, Fig.15 The illustration shows a unit 1510, which is abstracted into another unit 1520, and then split into two more units 1530 and 1536. Likewise, the units 1530 and 1536 can be merged to create 1520, and then expanded to return to the original unit 1510.

[0133] Figure 3 , Figure 4 , Figure 5 , Figure 7 , Fig. 9 as well as Fig.12Provide exemplary graphical representations of model entities and complete models according to the embodiments described herein. Systems and computer tools embodying such embodiments can use a variety of styles and different levels of abstraction to graphically represent models at different stages of the modeling process. Explicit model symbols other than graphics are also used to represent models, so that model design information is stored as software development artifacts, as final products, as intermediate data during the real-time modeling process, or as messages to be exchanged in a networked distributed modeling environment. Note that some embodiments described herein can be associated with methods for representing models in different formats. Models can be represented, for example, by metaclasses, which are used to represent complete information of block entities, control nodes, and logical flow network links. Models can be directly analyzed by directly accessing metaclass properties to check potential errors or consistency. Graphical representations (e.g., logic flow charts) can be presented by human developers for viewing underlying models. Software code can be generated, and the software code is compiled into target object code for operation and / or for review or testing by human developers.

[0134] Alternatively, if a programming language is pre-selected, the model can be directly represented by software code that follows a strictly predefined coding standard. By way of example, a block entity can be represented by the following Ada code block:

[0135] Issue_Gen_Pass:

[0136] --| Issuing passes to general individuals

[0137] --| Requirements: HLR_011; HLR_30

[0138] statement

[0139] Pass_Buffer: General_Pass_Type

[0140] start

[0141] Pass_Buffer.Name := Visitor_Name;

[0142] Pass_Buffer.Date:= Clock.Current_Date;

[0143] Pass_Buffer.Expiration:= Expiration_Time;

[0144] Issue_Pass(Pass_Buffer);

[0145] End Issue_Gen_Pass;

[0146] In this example, the block identifier is "Issue_Gen_Pass". Identification tags HLR_011 and HLR_30 are used to explicitly maintain traceability to higher-level requirements. Block input arguments include Visitor_Name and Expiration_Time. In this example, block parameters are made implicit (i.e., block parameters are short-circuited through block arguments) to avoid additional assignment statements. One issue with this short-circuiting is the additional overhead associated with automated model conversion. Note that there is only one block variable Pass_Buffer. Block actions include block actions to set up a pass buffer, and a call to the function Issue_Pass to cause the actual pass to be issued. Similar to the = example of the block entity, the control node can also be directly represented by software code that follows a strictly defined software standard.

[0147] As another example, the following may map a legacy code block to a block entity:

[0148] --| Collect airport information

[0149] Data_Base.Read

[0150] (index => Airport_Index,

[0151] -- The index of the previously recognized input

[0152] data => Airport_Data);

[0153] -- The airport information obtained as output

[0154] --| Runway-based search

[0155] --| Identifier and airport information.

[0156] Runway_Buffer := Search for runway

[0157] (Runway_Record => Airport_Data.Runway_Record,

[0158] -- Airport runway records as input

[0159] key => Runway_ID );

[0160] -- The previously provided ID as input

[0161] --| Extract runway information. If a runway is found, then

[0162] --| For specific airports.

[0163] if Runway_Buffer.Found, then

[0164] Data_Base.Read

[0165] (index => Runway_Buffer.Index,

[0166] -- Runway index as input

[0167] Data => Runway_Data);

[0168] -- The obtained runway information as output

[0169] end if;

[0170] Note that in the example above, the parts of the code block that start with the comment line indicated by the special sequence "--|" can contain block entities. The comment line indicated by the standard sequence "--" can serve as a regular comment within the block entity. Descriptive block entity identifiers can be created based on the comments indicated by the special sequence "--|" (e.g., "collect airport information", "search for runways", "extract runway information"). Identification tags for these block entities can be established according to the required traceability of the unit, and human intervention is adopted if necessary. Other items of the block entity can be established following the previous example. Note that the block entity "extract runway information" directly mapped from the last code block in the example will be a nested block entity because it contains a nested logic flow. The block entity can be expanded to establish a flat logic unit. If the logic flow in the model unit has not been changed after mapping (i.e., model extraction), the reverse mapping from the model to the most recently generated code will produce a code block that implements the same logic. However, each code block will be generated with appropriate block entity items, including, in addition to other items, identification tags that are not in the legacy code.

[0171] Traditionally, in a function or unit header, annotations are often used to describe logic flows in natural language. One problem with traditional approaches is the physical distance between the logic description and the actual code lines. This distance increases the difficulty of keeping the description and code synchronized. This distance also increases the difficulty of reviewing the code design and analyzing the code design. These difficulties often tend to lead to deviations between the logic description and the actual code that implements the logic. In using software code to represent the model, an embodiment can handle this problem by placing the logic description at the location of the actual code. Then, the code editing tool can show different levels of details of the code. For example, the developer can completely hide the code that will be similar to the conventional file header logic description (and only show annotations and tags). The required specifications can be pulled out from the specification model and shown in the code view, but not stored in the code file, or the required specifications can be automatically inserted into the code file as part of the code file content. Then, only the code for the control entity (together with the labeled annotations) is shown, which will be similar to some pseudo code. Just like conventional code files, all code lines can also be made visible. Traceability of high-level requirements is always embedded in block entities and control nodes. Another approach is to show only the code without any annotations. This can be advantageous for experienced programmers who wish to optimize the code manually. Although it is possible to represent the model in software code, given the additional overhead associated with direct model analysis and model conversion, a metaclass representation may be the preferred model representation when possible.

[0172] Methods for representing models as metaclasses and software code can provide a way to maintain a mapping between models represented as metaclasses and software code. This can be extended to automatically extract models from legacy software source code. Lists can be established (using mappings of search trees) to search for code language syntax to identify block entities and control nodes. The extraction method can be extended with new features or for different programming languages ​​by establishing a unified list structure, and then derived or instantiated to create mappings for specific programming languages ​​or application code bases.

[0173] Once the model is extracted and stored in a database, it can then be directly analyzed and enhanced to form a new underlying model for the software system. According to some embodiments described herein, the logic flow can be explicitly represented by block entities and control flow networks. In this way, the traceability between model elements and software code can be explicitly maintained. This allows full model coverage testing to be achieved by simulation of simulation runs using each block entity (including empty block entities). Code structure coverage testing and model coverage testing can be achieved simultaneously.

[0174] The distinction between the formal parameters and actual variables for block entities and control nodes allows the variable names to be changed in the unit without changing the representation of the logic in the model. For example, in a given problem domain, the algorithm is usually represented by the equation using the established naming. Mainly due to the attempt to avoid variable naming conflicts, such nomenclature cannot be used as easily as in the software code. While still maintaining the explicit traceability between the formal parameters and the actual variables, the distinction between the formal parameters and the actual variables decouples the model representation and the software code. This distinction also allows the easy conversion between the code block and the function. Or, this distinction can allow the unit with the internal logic of the unit represented by a batch of small and simple units in a block entity and a logic flow control network in a code generation configuration and another code generation configuration. Each of these two different software code configurations can have its advantages under different situations. This can be suitable for the long-term use of the production line with multiple product differences released in the entire history of the production line that still needs to be maintained.

[0175] Note that unit splitting and merging can be achieved in the generated code by expanding and abstracting nested block entities as a conversion between statement blocks to functions / procedures, embedded functions, and / or local functions.

[0176] Fig. 9 , Fig.10 as well as Fig.11 The method for extending and abstracting nested block entities as described in Fig.12 , Fig.13 as well as Fig.14 The method for modeling multiple units described in can be used as a way during model extraction and code generation to reorganize unit or block entity level local variables so that they can be rearranged to match specific programming language features and styles. For example, all local variables can be declared at the beginning of a unit regardless of which block entity the local variables are used in, or local variables can be declared when they are used for the first time.

[0177] As used herein, the term "component" may refer to a method (which can be implemented as computer software in a hardware system) that implements the required logic. However, the description does not have to be divided into a specific implementation scheme of the component on this issue. Note that the embodiments described herein can be implemented as a model-based software design computer system hosted by a single computer or a distributed computer interconnected by a network. In some embodiments, the method provides a set of functionality based on the model design. Each method can be constructed as a component of an overall computer system, and assembled and connected as software running on the same computer or on multiple distributed computers to form a system. Industry standards (such as Unified Modeling Language ("UML"), Object Management Group ("OMG") Meta-Object Facility, OMG Extensible Markup Language ("XML") Metadata Exchange together with others) can be used to interface with different software engineering tools.

[0178] In addition, the embodiments described herein can be implemented as model-based software design computer tools. In such embodiments, one or more methods can provide functionality for stand-alone component tools. Such component tools can be run to read, process and save model information in local or networked computer storage media. Such component tools can be run to retrieve, process and distribute to these tools from other tools hosted locally or remotely to achieve complete model-based design tasks. Industry standards (such as UML, OMG meta-object facilities, OMG XML metadata exchange together with others) can be used to interface with storage media or other model-based design tools. Alternatively, if reasonable, proprietary interfaces can be used.

[0179] Any number of different hardware configurations may be used to implement the embodiments described herein. For example, Fig.16 is a block diagram of the ASLM platform 1600. For example, the ASLM platform 1600 can be used with Figure 1 The ASLM platform 1600 includes a processor 1610 (such as one or more commercially available central processing units ("CPUs") in the form of a single-chip microprocessor), which is coupled to a communication device 1620 configured to communicate with each other via a communication network (not shown). Fig.16 16). The communication device 1620 can be used to communicate with, for example, one or more remote management terminals, user platforms, etc. The ASLM platform 1600 also includes an input device 1640 (e.g., a computer mouse and / or keyboard for inputting modeling or code information) and / or an output device 1650 (e.g., a computer monitor for presenting displays, creating reports, etc.). According to some embodiments, a mobile device and / or a PC can be used to exchange information with the ASLM platform 1600.

[0180] The processor 1610 also communicates with the storage device 1630. The storage device 1630 may include any suitable information storage device, including a combination of a magnetic storage device (e.g., a hard drive), an optical storage device, a mobile phone, and / or a semiconductor memory device. The storage device 1630 stores a program 1612 and / or an ASLM engine 1614 for controlling the processor 1610. The processor 1610 executes the instructions of the programs 1612 and 1614, and thereby operates according to any embodiment described herein. For example, the processor 1610 may access an ASLM data source, which includes an electronic record associated with a unit, each electronic record including a unit identifier, one or more identification tags, context data, unit parameters, unit variables, and internal logic. The processor 1610 may express system requirements at the logic block level, and establish a logic block as a self-contained entity and connection according to the system requirements (the established logic block graphically represents the system logic). Then, the processor 1610 platform may automatically convert the system logic explicitly to output language-independent public design information exchange model information. The processor 1610 platform may also translate and maintain traceability between system requirements, common design information exchange model information, and generated code.

[0181] Programs 1612, 1614 may be stored in a compressed, uncompiled, and / or encrypted format. In addition, programs 1612, 1614 may include other program elements such as an operating system, a clipboard application, a database management system, and / or device drivers used by processor 1610 to interface with peripheral devices.

[0182] As used herein, information may be, for example: (i) “received” or “transmitted” to the ASLM platform 1600 from another device; or (ii) “received” or “transmitted” to a software application or module within the ASLM platform 1600 from another software application, module, or any other source.

[0183] In some embodiments (such as, Fig.16 In the embodiment shown in ), the storage device 1630 further stores an ASLM database 1700, an HLR database 1660 (e.g., containing a set of high-level requirements that must be met), and a unit library 1670 (e.g., containing software units that can be reused by other developers). Fig.17Examples of databases that can be used with respect to the ASLM platform 1600 are described in detail. Note that the databases described herein are merely examples, and additional and / or different information may be stored therein. In addition, the various databases may be split or combined according to any of the embodiments described herein.

[0184] refer to Fig.17 , shows a table representing an ASLM database 1700, which can be stored at the ASLM platform 1600 according to some embodiments. The table can include, for example, entries identifying components associated with an electric power grid. The table can also define fields 1702, 1704, 1706, 1708, 1710 for each entry. The fields 1702, 1704, 1706, 1708, 1710 can specify according to some embodiments: ASLM identifier 1702, identification tag 1704, context 1706, unit parameters and variables 1708, and internal logic 1710. The ASLM database 1700 can be created and updated (for example, when a new project for implementing high-level requirements is started).

[0185] The ASLM identifier 1702 may be, for example, a unique alphanumeric code representing a descriptive name for explicitly identifying the intended functionality of the unit. One or more identification tags 1704 may explicitly maintain the traceability of the ASLM identifier 1702 and the unit itself to higher-level requirements (including derived requirements). The context 1706 may explicitly specify dependencies on entities external to the ASLM identifier 1702. Unit parameters and variables 1708 may represent formal data items that are expected to be received and output by the ASLM identifier 1702. Internal logic 1710 may represent specific functionality intended to be implemented by the ASLM identifier 1702 (and may be represented by a control flow network that connects block entities for the ASLM identifier 1702).

[0186] Thus, some embodiments described herein can provide a way to explicitly model arbitrary software logic at the block level. In addition, embodiments can explicitly convert software models (clearly explain each logic block) in fully extended flat logic, abstract nested logic and encapsulate nested logic, and split reusable units, all automatically following appropriate steps. Some embodiments can explicitly convert and maintain traceability between models of different forms (e.g., metaclasses, graphical representations, and software codes). A foundation for a complete tool chain can be provided to extract models from legacy code, to efficiently and effectively optimize and convert models, and / or generate code for testing and final release of complex, long-term, safety-critical avionics (and ground systems) software. Note that the internal logic of a software unit is equivalent to most of the resources allocated to software engineering (both in terms of man-hours and scheduling time). The embodiments described herein can establish a tool chain to handle the internal logic level design of a software unit, so as to continuously maintain, gradually improve, enhance, convert, and re-innovate complex software projects.

[0187] Various additional embodiments of the present invention are illustrated below. These embodiments do not constitute a definition of all possible embodiments, and those skilled in the art will appreciate that the present invention is applicable to many other embodiments. In addition, although the embodiments below are briefly described for clarity, those skilled in the art will appreciate how to make any changes to the above-described apparatus and methods, if necessary, to accommodate these and other embodiments and applications.

[0188] Although specific hardware and data configurations have been described herein, it is noted that any number of other configurations may be provided in accordance with embodiments of the present invention (e.g., some information associated with the database described herein may be combined or stored in an external system). Furthermore, it is noted that some embodiments may be associated with the display of information to developers. For example, Fig.18 An interactive graphical user interface ("GUI") display 1800 is illustrated that can display information about units 1810, 1820 that can be associated with an expansion process and / or an abstraction process. Use of a computer pointer 1850 may result in more detailed information being provided on the display 1800 (e.g., a pop-up window), adjustments to the units 1810, 1820, etc.

[0189] The present invention has been described with respect to several embodiments for purposes of illustration only. Those skilled in the art will recognize from this description that the invention is not limited to the embodiments described, but can be practiced with modification and alteration limited only by the spirit and scope of the appended claims.

[0190] Parts List

[0191] serial number describe

[0192] 100 Systems

[0193] 110 ASLM Data Source

[0194] 150 ASLM Platform

[0195] 155 GUI

[0196] 170 Remote User Platform

[0197] 300 units

[0198] 310 Unit identifier

[0199] 320 Identification Tags

[0200] 330 Context

[0201] 332 Unit Parameters

[0202] 334 Cell variables

[0203] 340 Internal Logic

[0204] 400 yuan

[0205] 410 Block Identifier

[0206] 420 Identification Tag

[0207] 430 Context

[0208] 432 Block Parameters

[0209] 434 Block variables

[0210] 440 Action

[0211] 500 Icons

[0212] 510 Node Identifier

[0213] 520 Identification Tag

[0214] 530 Variable

[0215] 520 Node Parameters

[0216] 534 Node variables

[0217] 540 Decision Control and Action

[0218] 550 Entering Node

[0219] 560 Control Node A

[0220] 570 Control Node B

[0221] 580 Control Node C

[0222] 590 Exit Node

[0223] 600 Process

[0224] 610 Start

[0225] 620 Selection

[0226] 630 Issuance of Passes

[0227] 640 cycles

[0228] 650 Pass issued

[0229] 690 End

[0230] 700 Icons

[0231] 710 Entering Node

[0232] 720 Select_Cat

[0233] 730 Issue_Ind_Pass

[0234] 750 Issue_Grp_Pass

[0235] 790 Exit Node

[0236] 900 Icon

[0237] 910 Pass Issuance Unit (Extended)

[0238] 920 Pass Issuance Unit (Abstract)

[0239] 1200 Graphics

[0240] 1210 Pass Issuance Unit (Merged)

[0241] 1220 Pass Issuing Unit (Split)

[0242] 1500 Graphics

[0243] 1510 Pass Issuance Unit (Abstract / Merge)

[0244] 1520 Pass Issuance Unit (Extended)

[0245] 1520 Pass Issuing Unit (Split)

[0246] 1600 ASLM Platform

[0247] 1610 processor

[0248] 1612 Program

[0249] 1614 Digital Twin Model

[0250] 1620 Communication device

[0251] 1630 Storage Components

[0252] 1640 Input Device

[0253] 1650 Output Device

[0254] 1660 HLR database

[0255] 1670 Cell Library

[0256] 1700 ASLM Database

[0257] 1702 ASLM Identifier

[0258] 1704 Identification Tags

[0259] 1706 Context

[0260] 1708 Unit Parameters and Variables

[0261] 1710 Internal Logic

[0262] 1800 Display

[0263] 1850 Computer pointer.

Claims

1. A system for facilitating arbitrary software logic modeling (ASLM) processing, comprising: an ASLM data source storing electronic records associated with a unit, each electronic record including a unit identifier, one or more identification tags, contextual data, unit parameters, unit variables, and internal logic; as well as An ASLM platform, coupled to the ASLM data source, includes a computer, the computer being programmed to: (i) Express system requirements at the logical block level; (ii) establishing the logic blocks as self-contained entities and connections according to the system requirements, the established logic blocks graphically representing the system logic; (iii) automatically and explicitly converting the system logic to output language-independent common design information exchange model information; (iv) transforming and maintaining traceability between the system requirements, the common design information exchange model information, and the generated code; as well as (v) running a merging process, the merging process comprising: identifying a block entity in a cell that references a combination of cells to be merged; Expanding the block variables of the parent block entity to include the cell variables from the cell to be merged; Transferring the internal logic of the unit to be merged to the nested sub-logic of the parent block entity; remapping arguments for block entities and control nodes incorporated into the nested sub-logic; After transferring the internal logic of the unit to be merged and expanding the block variables, updating the identification tag of the nested parent block entity and updating the registration of the parent block identifier in the high-to-low traceability mapping, and updating the identification tag and traceability mapping for the combined unit; deregistering the identification tag of the unit to be merged from the traceability map; deregistering the unit identifier of the unit to be merged from the data dictionary; and The unit to be merged is released.

2. The system according to claim 1, wherein: The system requirements include at least one of low-level requirements and high-level requirements, and the unit parameters define external unit interfaces and traceability to an ontology to allow automatic conversion of software component interfaces.

3. The system according to claim 1, wherein: At least one electronic record in the ASLM data source represents a block entity, the block entity including a block identifier, one or more identification tags, arguments, block parameters, block variables, and actions.

4. The system according to claim 1, wherein: The system logic includes at least one of the following items: a control node, a loop node, a merge node, an entry node, an exit node, and a null node.

5. The system according to claim 1, wherein: The ASLM platform further runs an extension process.

6. The system according to claim 5, wherein: The expansion process includes: Promote the parent block variable of the parent block entity to the unit variable; Remapping of arguments for block entities and control nodes in nested sub-logics; Merge the entry and exit nodes of the nested sub-logic with the control nodes in the unit's internal logic; Unregister the mapping of parent block identification tags from high to low traceability; Unregistering the parent block identifier from the data dictionary; and Releases the parent block entity.

7. The system according to claim 1, wherein: The ASLM platform further runs the abstraction process.

8. The system according to claim 7, wherein: The abstraction process includes: identifying subsections of logic to be abstracted; Create a new block entity and register the block identifier in the data dictionary; nesting the subsections of logic as actions of the new block entity; physically connecting the new block to the location where the logical subsection was originally connected; Creating arguments for said new block entity using logically nested said subsections; Establish block parameters for nested block entities; Creating a block variable for the nested block entity; and An identification tag is established for the nested block entity, and the nested block entity is registered in a high-to-low traceability mapping.

9. The system according to claim 1, wherein: The ASLM platform further runs the splitting process.

10. The system according to claim 9, wherein: The splitting process includes: Make nested block entities abstract for splitting into new units; Create a new unit and register the unit identifier in the data dictionary; establishing unit parameters for the new unit; Establishing a unit variable for the new unit; transferring the nested sub-logic of the nested block entity to the new unit; Generalizing the block entities and control nodes encapsulated in the new unit; Creating an identification tag for the new unit and registering the new unit in a high-to-low traceability map; Updating the nested block entity by referencing the new unit; An identification tag of the nested block entity is updated, and the block entity in the high-to-low traceability map is updated, and an identification tag of the original unit is updated.

11. A computerized method for facilitating arbitrary software logic modeling (ASLM) processing, comprising: accessing an ASLM data source that stores electronic records associated with a unit, each electronic record including a unit identifier, one or more identification tags, context data, unit parameters, unit variables, and internal logic; Expressing system requirements at the logic block level via a computer processor of an ASLM platform; Establishing the logic blocks as self-contained entities and connections according to the system requirements, the established logic blocks graphically representing system logic; Automatically and explicitly converting the system logic to output language-independent common design information exchange model information; Transform and maintain traceability between the system requirements, public design information exchange model information, and generated code; as well as A merge process is run, the merge process comprising: identifying a block entity in a cell that references a combination of cells to be merged; Expanding the block variables of the parent block entity to include the cell variables from the cell to be merged; Transferring the internal logic of the unit to be merged to the nested sub-logic of the parent block entity; remapping arguments for block entities and control nodes incorporated into the nested sub-logic; After transferring the internal logic of the unit to be merged and expanding the block variables, updating the identification tag of the nested parent block entity and updating the registration of the parent block identifier in the high-to-low traceability mapping, and updating the identification tag and traceability mapping for the combined unit; deregistering the identification tag of the unit to be merged from the traceability map; deregistering the unit identifier of the unit to be merged from the data dictionary; and The unit to be merged is released.

12. The method according to claim 11, wherein: The system requirements include at least one of low-level requirements and high-level requirements.

13. The method according to claim 11, wherein: At least one electronic record in the ASLM data source represents a block entity, the block entity including a block identifier, one or more identification tags, arguments, block parameters, block variables, and actions.

14. The method according to claim 11, wherein: The system logic includes at least one of the following items: a control node, a loop node, a merge node, an entry node, an exit node, and a null node.

15. The method according to claim 11, wherein: The ASLM platform further runs at least one of the following: an expansion process, an abstraction process, and a splitting process.

16. A non-transitory computer-readable medium storing instructions that, when executed by a computer processor, cause the computer processor to perform a method for facilitating arbitrary software logic modeling (ASLM) processing, the method comprising: accessing an ASLM data source storing electronic records associated with a unit, each electronic record comprising a unit identifier, one or more identification tags, context data, unit parameters, unit variables, and internal logic; Expressing system requirements at the logic block level via a computer processor of an ASLM platform; Establishing the logic blocks as self-contained entities and connections according to the system requirements, the established logic blocks graphically representing system logic; Automatically and explicitly converting the system logic to output language-independent common design information exchange model information; Transform and maintain traceability between the system requirements, public design information exchange model information, and generated code; as well as A merge process is run, the merge process comprising: identifying a block entity in a cell that references a combination of cells to be merged; Expanding the block variables of the parent block entity to include the cell variables from the cell to be merged; Transferring the internal logic of the unit to be merged to the nested sub-logic of the parent block entity; remapping arguments for block entities and control nodes incorporated into the nested sub-logic; After transferring the internal logic of the unit to be merged and expanding the block variables, updating the identification tag of the nested parent block entity and updating the registration of the parent block identifier in the high-to-low traceability mapping, and updating the identification tag and traceability mapping for the combined unit; deregistering the identification tag of the unit to be merged from the traceability map; deregistering the unit identifier of the unit to be merged from the data dictionary; and The unit to be merged is released.

17. The medium according to claim 16, wherein The system requirements include at least one of low-level requirements and high-level requirements.

18. The medium according to claim 16, wherein: At least one electronic record in the ASLM data source represents a block entity, the block entity including a block identifier, one or more identification tags, arguments, block parameters, block variables, and actions.

19. The medium according to claim 16, wherein: The system logic includes at least one of the following items: a control node, a loop node, a merge node, an entry node, an exit node, and a null node.

20. The medium of claim 16, wherein: The ASLM platform further runs at least one of the following: an expansion process, an abstraction process, and a splitting process.

Images