Software code sharing is important, as the current state-of-the-art allows for the sharing of subroutines (sometimes called methods) and libraries of subroutines. The term “subroutine” in computer-science typically refers to a named block of code which may have a parameter list and which may have a return value. This block of code can be accessed from within another code block via the use of its name and parameter list. There can be significant amounts of code within the subroutine. Sharing portions of a subroutine is not possible unless the to-be-shared code portion is itself a subroutine. Rather than requiring the entire subroutine be shared, it is more efficient to share only that portion of the subroutine that is required to be shared.
In prior art software code and software design quickly become disassociated.
In addition to automatic software element association, typically, the creation of a complex software system entails creating and managing a project. The most common project management tools are the Gantt and PERT (Program Evaluation and Review Technique) charts. Microsoft Corporation has shown that a Gantt chart can be converted into a PERT chart and vice versa. These charts are composed of tasks, time durations for each task, task dependencies, and starting dates for each task. The various tasks and their associated attributes are currently manually entered and manually maintained. This is because the current project management tools are general tools which are separate from software design.
To maintain code/design and file/database/design association, the code and/or file/database are automatically, versus manually, located in a file, database, library, or cloud. With automatic code-design and file/database-design association, a developer simply designs while code and/or files/databases are located and associated automatically. Contrast this with source-code sharing models that require the developer to first find then analyze and finally associate blocks of code or locate and verify files and databases. Once code/files/databases and design are reliably associated then new, better code/files/databases may also be automatically located to replace existing code blocks, effectively allowing automatic code/file/database upgrading.
In one embodiment, a system for automatically associating a software code block with a design element of a software design, includes: a processor; a memory communicatively coupled with the processor storing: the software design having the design element, the design element having (i) a list of keywords and (ii) test procedures associated therewith; and an associator stored within the memory as non-transitory computer readable instructions that when executed by the processor associate the software code block with the design element.
In another aspect, a method for automatic Gantt chart creation of a software design having a plurality of elements, includes: receiving, at a project manager comprising non-transitory computer readable medium stored on memory communicatively coupled to a processor of a software development system, completion information of the elements of the software design; generating completion date information based upon a date that code blocks are assigned to each of the elements; and generating a visual representation of a Gantt chart including the completion information and the completion date information.
Metadata is information about a thing rather than the thing itself. For automatic code search/test/design association the required code metadata is a keyword list for each block of code and a list of all inputs and outputs to/from the code block. Similarly each decomposition design element (process bubble) must also have an associated keyword list, input/output list (from the design), and test procedures.
Software design 110 contains at least one element 112 that has associated input/output and loop information 113 that defines inputs, outputs, and loop structures of element 112. Software design 110 is for example a hierarchical functional decomposition software design as disclosed in U.S. application Ser. No. 13/425,136 (e.g. decomposition of algorithm 117 within application Ser. No. 13/425,136).
Element 112 also has associated metadata 114 that may include a list of keywords that describe element 112. Each element 112 may be one or more of control kernel, process kernel, data transformation, control transformation, control bubble and process bubble as defined in the '136 App. Code block 116 has associated input/output and loop information 113 that defines inputs, outputs, and loop structures of code block 116. Code block 116 also has associated metadata 118 that may include a list of keywords that describe operation of code block 116. Associator 108 operates, using a list 109, to automatically select code block 116 for use within an implementation of software design 110 based upon (a) matching of input/output and loop information 113 with input/output and loop information 113 and (B) matching of metadata 118 with metadata 114.
In step 202, method 200 adds at least one code block to a list based upon keyword matches in metadata. In one example of step 202, associator 108 compares keywords of metadata 118 of each code block 116 with keywords of metadata 114 of element 112 and adds code block 116 to list 109 if the keywords match.
In step 204, method 200 eliminates code blocks that do not have matching input/output and loop information from the list. In one example of step 204, associator 108 compares, for each code block 116 within list 109, input/output and loop information 113 with input/output and loop information 113 of element 112, and remove code blocks from list 109 where input/output and loop information 113 does not match input/output and loop information 113.
Steps 206 through 214 form a loop 207 that repeats for each code block within list 109. In step 206, method 200 selects a first, and subsequently a next, code block from the list. In one example of step 206, associator 108 selects a next code block from list 109.
In step 208, method 200 tests the code block using test procedure of the design element. In one example of step 208, associator 108 uses test procedure 130 to test code block 116 selected in step 206.
Step 210 is a decision. If, in step 210, method 200 determines that the test results are correct, method 200 continues with step 214; otherwise method 200 continues with step 212. In step 212, method 200 removes the code block from the list. In one example of step 212, associator 108 removes code block 116 from list 109 within memory 102.
Step 214 is a decision. If, in step 214, method 200 determines that at least one unprocessed code block is within the list, method 200 continues with step 206 to repeat loop 207; otherwise method 200 continues with step 216.
In step 216, method 200 selects a code block from the list that best matches developer goals. In one example of step 216, associator 108 evaluates each remaining code block 116 within list 109 and selects the code block that matches design goals 111.
In step 218, method 200 associates the code block with the design element. In one example of step 218, associator 108 associates code block 116 with design element 112.
Unlike traditional software development systems, system 100 does not associate test procedures 130 with code blocks 116. Rather, system 100 associates test procedures 130 with design element 112 (e.g., a transformation processes) of software design 110. By associating test procedures 130 with design element 112, each code block 116 remaining in list 602 may be evaluated against test procedure 130. Test procedure 130 comprises input data and expected output data, and therefore each code block within list 602 is tested, using the test procedure and input data, to determine whether it generates the correct output data. Code blocks 116 that do not generate the correct output data for test procedure 130 are culled from list 602.
After third step 900, only a few code blocks 116 remain within list 602. One additional step is used to decrease list 602 to one code block: developer goals. A developer of design 110 defines the overall goals 111 they are trying to achieve with design 110.
A data store in system 100 is similar to a “C” or “C++” language data structure. That is, software that is designed within system 100 is executed to processes data within these data structure type data stores. Data stores do not directly represent data that is stored within files and databases. That is, files and databases are not directly attached to High Level Design Process Elements (HLD-PEs) within software design 110.
Where the schema flag indicates “no”, a schema is not available for that database type, and the Schema button is gray and is not selectable. When the schema flag indicates “yes”, the schema button is selectable.
The first time a table is defined it is placed into the selected database using the SQL CREATE TABLE for SQL databases or a similar command for NoSQL databases. Adding data to an existing database table is performed using the SQL UPDATE (for SQL databases) or similar command for NoSQL databases to be generated. The SQL schema may be changed using ALTER, DROP, DELETE, or TRUNCATE commands for SQL databases or similar commands for NoSQL databases.
The first time data is placed into the selected database, a CREATE TABLE (for SQL databases) or similar command for NoSQL databases is generated. Adding data to an existing database generates an UPDATE (for SQL databases) or similar command for NoSQL databases. Changing schema 1800 causes an ALTER command to be generated for SQL databases or similar command for NoSQL databases.
Since a file or a database may exist outside of a program, it is very useful to be able to locate the proper file or database. For use herein, the term “exist outside of a program” is used to define a file or database located outside of a software design 110 within the development environment 100. Considering that the file format (for flat files) and schemas (for SQL databases) and keys (for key-value type NoSQL databases) all define how to access the data, these data access methods may be used to find the correct file or database. First determine if the keyword search will be against files or databases and if against databases whether the database is SQL or NoSQL. Second use the keyword search to create a list of potential file/databases.
If more than one file/database remains within list 2202 then the one file/database in the list that best meets the goals defined by the developer using table 900 of
In step 2502, method 2500 adds files/databases to a list based upon keyword matched in metadata. In one example of step 2502, associator 108 compares keywords of metadata 1218 of each file/database 1216 with keywords of metadata 1214 of data store 1212 and adds file/database 1216 to list 1209 if the keywords match.
In step 2504, method 2500 eliminates files/databases that do not have matching access methods from the list. In one example of step 2504, associator 108 compares, for each file/database 1216 within list 1209, access method 1217 with access method 1213 of data store 1212, and removes file/database 1216 from list 1209 where access method 1217 does not match access method 1213.
Steps 2506 through 2514 form a loop 2507 that repeats for each file/database 1216 within list 1209. In step 2506, method 2500 selects a first, and subsequently a next, file/database from the list. In one example of step 2506, associator 108 selects a next file/database 1216 from list 109. In step 2508, method 2500 tests the file/database using a test query of the data store. In one example of step 2508, associator 108 uses test query 1230 to test file/database 1216 selected in step 2506.
Step 2510 is a decision. If, in step 2510, method 2500 determines that the test results are correct, method 2500 continues with step 2514; otherwise method 2500 continues with step 2512. In step 2512, method 2500 removes the file/database from the list. In one example of step 2512, associator 108 removes file/database 1216 from list 1209.
Step 2514 is a decision. If, in step 2514, method 2500 determines that at least one unprocessed file/database is within the list, method 2500 continues with step 2506 to repeat loop 2507; otherwise method 2500 continues with step 2516.
In step 2516, method 2500 selects a file/database from the list that best matches developer goals. In one example of step 2516, associator 108 evaluates each remaining file/database 1216 within list 1209 and selects the file/database that matches design goals 111.
In step 2518, method 2500 associates the file/database with the data store. In one example of step 2518, associator 108 associates file/database 1216 with data store 1212. Data store 1212 may then be used by associator 108 for identifying code blocks within data store 1212 that match element 112.
Automatic Gantt Chart Creation:
Software design 2610 is similar to software design 110, of
Completion information 2680 is manually entered by a developer, using developer computer 150, or automatically generated by project manager 2608. Project manager 2608 then utilizes such information to automatically generate a project Gantt chart 2620. Project Gantt chart 2620 is then used in conjunction with design representation 2622 which is a visual representation of software design 2610 including completion information 2680. Each of Gantt chart 2620 and design representation 2622 may be displayed on display 152 of developer computer 150. Moreover, a developer may interact with each of Gantt chart 2620 and design representation 2622 using input device 154 and interface 156 of developer computer 150.
Within design 2700, where a process is equated to a task to be performed, then each decomposition level may represent a group of linked tasks. Within a given decomposition level, processes are linked together using control flows attached to the central control process. A control flow is specifies when some process is to be called. The control flow contains three types of conditional statements: “init”, “if”, and “call-after” or some combination of “if” and “call-after”. The “init” conditional statement represents the beginning of a series of processes. For example, an “init” condition is illustrated by control flow 2602. With regards to project management, the first series of processes must have a start-by date and duration. Where a control flow attached to a process does not contain either an “init” or a “call-after” conditional statement then it is considered the beginning of a series of processes. A series can be one or more processes linked together. The “call after” conditional statement represents a sequence of activity: the current process is called after some other process has completed.
Each process, or decomposition level, defines an individual element 2612 within design 2610. Project manager 2608 automatically generates completion information 2680 for each element 2612.
Within completion information 2680, the start by date 2682, and duration 2684 may be manually entered by a developer by using input device 154 and right-clicking on the process of interest within design representation 2630 when displayed on display 152. Where a particular process includes a call-after in its conditional statement, such as process 2806 within design 2800, project manager 2808 automatically generates the start date as “n/a”.
Where an element within design 2610 cannot be automatically associated, project manager 2608 may automatically determine the most critical element of design 2610 that needs to be developed.
Critical path may additionally be illustrated on the Gantt chart 2620. For example,
Project manager 2608 may further calculate the completion percentage 2692 of a given software design 2610. Completion percentage 2692 be displayed via the Gantt chart 2620.
Project manager 2608 may further automatically estimate the completion date of the entire design 2610. Referring back to
Moreover, project manager 2608 may then estimate the percentage of the project that is completed based upon the completed elements divided by the estimated number of required elements. Completed elements may be identified by those elements having a completion percentage of 100% within completion data 2692.
Further yet, project manager 2608 may identify the estimated time it will take to complete a project. The time to complete a project is estimated by the average duration per completed element times the average number of developers per element times the estimated number of processes minus the elapsed time. Average duration per completed element is based upon duration 2684. Average number of developers per element is based upon assignee information 2690.
The estimated completion date, estimated time to complete a project, and the estimated percentage complete may all be indicated on Gantt chart 2620 and/or design representation 2630.
In optional step 3402, method 3400 divides a software design into individual elements. In one example of optional step 3402, project manager 2608, or associator 108, divides software design 2610 into a plurality of individual elements 2612. Elements 2612 may form a hierarchical software design. Alternatively, in one example of step 3402, software design 2610 is manually divided into a plurality of elements 2612 by a developer or administrator.
In step 3404, method 3400 receives completion information from a developer. In one example of operation of step 3404, program manager 2608 receives completion information 2680 including start by date 2682, duration 2684, and assignee information 2690 from a developer using developer computer 150.
In step 3406, method 3400 associates code blocks with software design elements. In one example of step 3406, program manager 2608 cooperates with associator 108 to automatically associate code blocks 116 with elements 112 (i.e. elements 2612). In another embodiment, program manager 2608 includes the functionality to automatically associate code blocks with each element 2612. In another embodiment, a developer develops code blocks for each element 2612. It should be appreciated that not all elements 2612 need to be associated or developed at the same time.
In step 3408, method 3400 generates completion date information for each completed element. In one example of step 3408, method 3400 automatically generates completion date 2688 based upon the date of automatic association via associator 108. In an additional example of step 3408, project manager 2608 receives the completion date from a developer using developer computer 150. Project manager 2608 then stores the received completion date as completion date 2688 in memory 2602.
In step 3410, method 3400 generates critical path information. In one example of step 3410, project manager 2608 generates critical path information 2686 for each element 2612 that does not have a code block associated therewith. Project manager 2608 may further prioritize completion of each unassociated element based upon any the critical path information 2686.
In step 3412, method 3400 generates completion percentage information. In one example of step 3412, project manager 2608 generates completion percentage information 2692 based upon the number of elements associated with a code block compared to the number of unassociated elements.
In step 3414, method 3400 generates a visual representation of a Gantt chart. In one example of step 3414, project manager 2608 generates Gantt chart 2620 and/or design representation 2630 including element completion information 2680 therein.
In step 3416, method 3400 generates estimated completion information of the entire software design. In one example of operation, project manager 2608 determines the estimated total number of required elements that will be required for completion of development of design 2610 based upon the average number of elements per requirements with at least one associated element multiplied by the number of requirements 2640. Project manager 2608 may then estimate the percentage of completion based upon the completed elements divided by the estimated number of required elements. Project manager 2608 may then identify the estimated time to complete software design 2610 based upon the average duration per completed element multiplied by the average number of developers per element multiplied by the estimated number of elements minus the elapsed time.
Changes may be made in the above methods and systems without departing from the scope hereof. It should thus be noted that the matter contained in the above description or shown in the accompanying drawings should be interpreted as illustrative and not in a limiting sense. The following claims are intended to cover all generic and specific features described herein, as well as all statements of the scope of the present method and system, which, as a matter of language, might be said to fall therebetween.
This application is a continuation-in-part of and claims the benefit of priority to U.S. patent application Ser. No. 13/425,136, filed Mar. 20, 2012, entitled “Parallelism from Functional Decomposition”. This application further claims the benefit of priority to U.S. patent application Ser. No. 13/490,345, filed Jun. 6, 2012 entitled “Method for Automatic Extraction of Designs from Standard Source Code”; U.S. Provisional Patent Application Ser. No. 61/835,477, filed Jun. 14, 2013 and entitled “System and Method for Automatically Associating Software Components”; and U.S. Provisional Patent Application Ser. No. 61/841,004, filed Jun. 28, 2013 and entitled “System and Method for Automatically Associating Software Elements”. Each of the aforementioned applications are incorporated herein by reference.
Number | Date | Country | |
---|---|---|---|
61835477 | Jun 2013 | US | |
61841004 | Jun 2013 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 13425136 | Mar 2012 | US |
Child | 14306126 | US | |
Parent | 13490345 | Jun 2012 | US |
Child | 13425136 | US |