Patent Grant
7861227
The present invention relates generally to project management and, more specifically, to automatically checking and validating a software class specification.
Product development projects typically require significant effort to monitor and manage. Furthermore, computer software development projects are inherently difficult to manage. This difficulty is partly due to the large number of tasks and associated deliverables that comprise a software package and the vastness of paperwork and project files associated with these tasks and deliverables. Another contributing factor are the complex interdependencies established between individual tasks and deliverables during the development cycle of a software package. Yet another contributing factor is the need to generate and maintain a design specification associated with the software being developed.
Management of development projects typically includes organizing, maintaining, and controlling access to project documents, schedules, and the like. Furthermore, there are often multiple development projects occurring concurrently within an enterprise organization, thus significantly expanding the document management efforts. Historically, management of a master project schedule entails, among other tasks, manually entering data into a scheduling application, manually creating links between schedules, and manually aggregating individual developers' task schedules into the master project schedule. These are cumbersome and error-prone tasks, with little to no oversight and quality control.
A master project schedule is often in a state of flux, whereby management solicits the developers for task statuses and related schedule updates. Often, the feedback provided to management by the developers has little oversight and is not according to a rigid policy, procedure, or validation process. Thus, the actual status of a project schedule is often difficult to ascertain since the progress of individual tasks are dictated by subjective, and often self-supporting, progress reports by those individuals that are assigned to the task.
For example, some scheduling systems allow a developer to signify that a task is partially completed, i.e., ninety percent completed. This information is then entered into the scheduling system to determine whether the project is on-schedule. However, because there is generally no accountability as to whether an individual's status is reliable, the current process of obtaining project status tends to shadow the realistic progress of the project.
In view of the foregoing, there is a clear need for a technique for management of interdependent development project task schedules that reduces the manual tasks related thereto.
Furthermore, during the development of software, generating and maintaining accurate and consistent design specifications is a challenge. Sometimes variable names are misspelled or used inconsistently within the design specification and often these errors go undetected in the inspection process. Furthermore, sometimes variable names referenced in a design specification are inconsistent with organization rules, constraints and processes, such as variable naming rules.
If a design specification contains incorrect or inconsistent variable names that go undetected during the document inspection process, then these errors are usually detected by a compiler when the software code associated with the specification is compiled. In such a scenario, time and resources are wasted in correcting the errors, both in the code and in the design specification. In some organizations, design specifications must also abide by the organization's document change control process. Thus, the wasting of resources is exacerbated because a revised specification document requires generation of a document change request and further inspection of the document and the change request, which presents additional costs and results in additional wasting of resources. In view of the foregoing, there is a clear need for an automated technique for checking and verifying the accuracy and consistency of a software design specification document. For example, there is a need for validating various aspects of a class specification.
A technique for validating a software class specification file includes automatically determining whether the class specification file includes all the sections that class specifications are required to have according to document rules and, if so, determining whether the sections are correctly ordered.
Various embodiments involve further validating the class specification file for consistency across the sections of the class specification. Specifically, the class specification file is validating with respect to proper (a) declaration of defined functions; and (b) specification of variables. Validating proper specification of variables includes validating (b1) class attributes, for attributes specified at either the class level or attributes specified for structures and nested classes defined in a defined type list; and (b2) parameters corresponding to functions defined in the class specification, for functions defined at either the class level or functions defined for structures and nested classes defined in a defined type list; and (b3) local variables referenced in corresponding function definitions.
A validator tool, which is accessible over a network via a web page, traverses the sections of the electronic class specification file. For example, the validator reads a Function List section, a Defined Type List section, and a Class Attributes section, and identifies and stores the various function names and variable names encountered in the class specification file. The validator then processes a Function Definitions section of the class specification file by identifying the defined functions and referenced variables, and checking these against the function and variable names already encountered in the other sections of the class specification file. Results are displayed on a web page, indicating the functions that are defined in the class specification and any undeclared functions and/or unspecified variables.
Hence, occurrences of misspelled, missing, or out of order functions and unspecified parameters and attributes in an electronic class specification file are discovered in an automated manner before proliferation of such errors to the software code associated with the class specification. Thus, in many cases, use of resources associated with correcting a controlled document, such as the class specification, is reduced or avoided. Further, subsequent compiler-time errors are reduced or avoided.
The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:
Techniques for automating tasks involved in the management of a development project are described. The techniques are described herein primarily in reference to a software development project, but those skilled in the art should recognize that the benefits of the invention are also available when applying the techniques to other development projects. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.
Operating Environment
Workstations 102 are typically computer systems configured as illustrated by the computer system 200 of
Web server 104 depicts a conventional web server, which is a combination of computer hardware and software that, using the appropriate protocols (e.g., Hypertext Transfer Protocol [HTTP] and Transmission Control Protocol/Internet Protocol [TCP/IP]), serves the files that form web pages (e.g., Hypertext Markup Language [HTML] or Extensible Markup Language [XML] files), to users, such as developers or managers at a workstation 102. In general, the majority of information exchanged and managed during the development project life cycle is served by the web server 104 over the network 108. Furthermore, aspects of the techniques for automating management of development project files, as described herein, may be implemented and executed on the web server 104, although practice of the invention is not limited to such an implementation. The techniques could also be implemented on any other processing system, such as workstation 102 or a similarly configured computer system as illustrated in
Database 106 depicts a conventional database for storing information related to the development project, thus providing access to the information by authorized individuals at workstations 102 or web server 104, through queries transmitted over the network 108. The type of information stored on database 106 is virtually limitless, non-limiting examples including project initiation forms, individual and aggregated management task schedules, specifications, software code, inspection reports, web page files, and document directories and indexes. In addition, other information may be stored on the database 106, as illustrated in and described in reference to
Network 108 depicts a conventional network, e.g., a packet-switched network, for facilitating the exchange of information between and among various connected components, such as workstation 102, web server 104, and database 106. The network 108 may be a Local Area Network (LAN), such as a conventional Ethernet, Fast Ethernet, a token ring, or a wireless LAN such as specified in 802.11a and 802.11b (developed by a working group of the Institute of Electrical and Electronics Engineers [IEEE]), which may be implemented within an enterprise. In addition, network 108 may also be a Wide Area Network (WAN), such as the Internet, for facilitating communication with remote users through a Virtual Private Network (VPN), or the network 108 may represent a combination of a LAN and a WAN. In addition, network 108 can be formed using a variety of different mediums, including but not limited electrical wire or cable, optical, or wireless connections.
Hardware Overview
Computer system 200 may be coupled via bus 202 to a display 212, such as a cathode ray tube (CRT) or a liquid crystal display (LCD), for displaying information to a computer user. An input device 214, including alphanumeric and other keys, is coupled to bus 202 for communicating information and command selections to processor 204. Another type of user input device is cursor control 216, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor 204 and for controlling cursor movement on display 212. This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a plane.
The invention is related to the use of computer system 200 for implementing the techniques described herein. According to one embodiment of the invention, those techniques are performed by computer system 200 in response to processor 204 executing one or more sequences of one or more instructions contained in main memory 206. Such instructions may be read into main memory 206 from another computer-readable medium, such as storage device 210. Execution of the sequences of instructions contained in main memory 206 causes processor 204 to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the invention. Thus, embodiments of the invention are not limited to any specific combination of hardware circuitry and software.
The term “computer-readable medium” as used herein refers to any medium that participates in providing instructions to processor 204 for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Examples of non-volatile media include, without limitation, optical, magnetic disks, or magneto-optical disks, such as storage device 210. Volatile media includes dynamic memory, such as main memory 206. Transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise bus 202. Transmission media can also take the form of acoustic or light waves, such as those generated during radio-wave and infra-red data communications.
Common forms of computer-readable media include, without limitation, a floppy disk, a flexible disk, hard disk, magnetic tape, any other magnetic medium; a CD-ROM, DVD, any other optical or magneto-optical medium; punchcards, papertape, any other physical medium with patterns of holes; a RAM, a PROM, an EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read.
Various forms of computer readable media may be involved in carrying one or more sequences of one or more instructions to processor 204 for execution. For example, the instructions may initially be carried on a magnetic disk of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to computer system 200 can receive the data on the telephone line and use an infra-red transmitter to convert the data to an infra-red signal. An infra-red detector can receive the data carried in the infra-red signal and appropriate circuitry can place the data on bus 202. Bus 202 carries the data to main memory 206, from which processor 204 retrieves and executes the instructions. The instructions received by main memory 206 may optionally be stored on storage device 210 either before or after execution by processor 204.
Computer system 200 also includes a communication interface 218 coupled to bus 202. Communication interface 218 provides a two-way data communication coupling to a network link 220 that is connected to a local network 222. For example, communication interface 218 may be an integrated services digital network (ISDN) card or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface 218 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, communication interface 218 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.
Network link 220 typically provides data communication through one or more networks to other data devices. For example, network link 220 may provide a connection through local network 222 to a host computer 224 or to data equipment operated by an Internet Service Provider (ISP) 226. ISP 226 in turn provides data communication services through the world wide packet data communication network now commonly referred to as the “Internet” 228. Local network 222 and Internet 228 both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on network link 220 and through communication interface 218, which carry the digital data to and from computer system 200, are exemplary forms of carrier waves transporting the information.
Computer system 200 can send messages and receive data, including program code, through the network(s), network link 220 and communication interface 218. In the Internet example, a server 230 might transmit a requested code for an application program through Internet 228, ISP 226, local network 222 and communication interface 218.
The received code may be executed by processor 204 as it is received, and/or stored in storage device 210, or other non-volatile storage for later execution. In this manner, computer system 200 may obtain application code in the form of a carrier wave.
Project Database
Project data 310 refers to project-specific documents that may include, but are not limited to, completed project initiation forms (see
Different levels of project-specific information can be accessed from the database 106, as is depicted by a projects home page 312 and one or more project sites 314. The projects home page 312 provides links to the one or more project sites 314. As is known in the art, a link is a selectable connection from one word, picture, or information object to another. One non-limiting example of an implementation of a link is a hyperlink, utilizing a suitable protocol and language such as HTTP and HTML, respectively. The links allow a user to access the project sites 314 from the home page 312, by enacting the link. The link is enacted typically through use of the cursor control 216 (
Initiating Automated Project File Management
An example of a printed or displayed project initiation form 550, illustrating pertinent information headings with the information excluded, is illustrated in
Referring back to
Inspection Process—Client
Inspection Process—Server
Once it is determined at decision block 490 that the material has been certified by the inspection chief, the process continues to step 492, which is the same step that is performed if the reference material is accepted at block 486. At step 492, the current inspection material is copied into database 106 (
Project Web Pages
The directory 602 presents links to indexes of various official documents and records associated with the project, for non-limiting examples, project documents, inspection results, meeting records, changes, error tracking, and other records.
The project schedule link 608 provides access to the aggregated management task schedule, which is exemplified in and described in reference to
Method for Managing Project Files Over a Network
At step 808 of
At step 818 of
Upon completion of a draft file, the status of the file is changed from draft to official and it is stored in the database 106 indicating its status, at step 820. Alternatively, the physical file may be copied into the secure file system and the reference to the file stored in the database 106. Finally, at step 822, the official file is linked to the project site. As exemplified in reference to
Management Schedule Generation
The completion of each task in the individual task schedules is linked to inspection forms, completed versions of which are stored in the database 106 (
Referring to
Referring to
Updating a Project Schedule
At step 1504, an individual's task schedule (i.e., the individual responsible for completing the task), is automatically updated based on the received inspection forms. According to a policy, a project task is not completed unless the inspection result report so indicates, or unless the chief inspector certifies the corrections to the product in the case where the inspection result indicates a conditional acceptance, as shown in
In one embodiment, the individual and management schedules are governed by a policy specifying that a project task cannot be partially completed and the automatic updating of the schedules is performed according to this policy.
At step 1508, the completed project task product is stored in the database 106 (
Task Hierarchy
According to an embodiment of the invention, a task hierarchy is used to manage a development project. A task hierarchy represents relationships among tasks that are related to completion of a development project. In one embodiment, the relationships represent dependencies among task in the hierarchy, such that completion of a parent task depends on completion of one or more lower-level child tasks. Therefore, the dependencies specify how changes to a member task in the hierarchy affects other member tasks in the hierarchy, if at all. The use of a task hierarchy facilitates the automated update of project task schedules in response to changes to lower level task schedules.
Note that a task at any particular level is not required to have associated sub-tasks. For example, task 1602 (Design Document Guideline) and task 1604 (J07 Project Plan), which are defined as level 1 tasks, are not defined to have any associated lower level tasks. In addition, the level 2 tasks collectively identified as tasks 1608 (Common, Send Service, and Send Timer), are not defined to have any associated level 3 tasks that require completion to complete the tasks 1608. As depicted in
TASK DATA STRUCTURE
The task schedule 1704 comprises dates related to performance of the task. In one embodiment, the dates include a “planning date”, a “planned start” date, a “planned end” date, an “actual start” date, and an “actual end” date. The planning date indicates the latest date on which any of the other task schedule dates were entered or updated. In one embodiment, the current date (i.e., the date on which an entry or change to a schedule is made) will automatically be retrieved from the system clock and entered into the appropriate planning date field. The substance of the other task schedule dates, that is, the planned and actual dates, is self-explanatory. Manipulation of these fields can be performed through use of an on-line task scheduler form, illustrated in
Implementation of the task schedule 1704 can take multiple forms and remain within the scope of the invention. For example without limitation, the task schedule 1704 can be implemented using vector, map, list, or struct classes of programming objects.
The vector of lower-level references 1706 is a programming tool used to provide references from a particular task to lower level tasks in the hierarchical structure of tasks. For example, a level 2 task, such as task 1612 (
The parent reference 1708 is used to provide a reference from a particular task to an associated higher level, or parent, task in the hierarchical structure of tasks. For example, a level 2 task, such as task 1612 (
The vector of history 1710 provides a reference from a particular task to historical data related to the particular task. For example, the vector of history 1710 can be implemented as a simple pointer to a location of data representing historical dates associated with the particular task. Thus, a task schedule can include historical (or “old,” or “obsolete”) dates for any of the date fields, such as planned start, planned end, actual start, and actual end, along with current dates, such as referred to collectively as element 1210 of
Furthermore, parent references of parent object 1820 are accessed to identify any parents of task object 1820, so that a determination can be made as to whether the schedule data of the parent task object at the next higher level requires updating as a result of the change to the schedule data of task object 1840 and the resultant change to object 1820. For example, the parent references of object 1820 points to task object 1800. Task object 1800 is accessed to identify its child references. For example, the vector of lower-level references for task object 1800 points to the three children tasks of task object 1800, which are task object 1810, task object 1820, and task object 1830. Once the child tasks are identified, the schedule data for the child task objects (i.e., 1810, 1820, and 1830) is accessed and analyzed to determine whether any of the schedule dates of their parent object 1800 requires updating as a result of the change to the schedule data of grandchild object 1840. This process is performed along all necessary levels of the task hierarchy until the top level (Level 1) is reached and any required updates to task schedules at the top level are determined. According to an embodiment of the invention, a method for updating a task schedule data structure, which illustrates in more detail the analysis of task schedule dates, is illustrated in
Task Management Tools
The task assignment form 1900 further includes pull-down menus, such as “Major Task List” menu 1906 and “Task Level” menu 1908. In certain instances, particular tasks may be required of a development project, due, for example, to company policy or the nature of the development project. In such instances, the menu 1906 can be programmed to include such required tasks. Consequently, the pull-down menu 1906 can be utilized by a project participant, for example, an engineering manager or project lead, when assigning project tasks through the on-line task assignment form 1900. Furthermore, as major, or high-level, tasks are identified for the project, they can be added to the menu 1906 by someone such as an administrator or a project manager. In one implementation, the menu 1906 includes only major tasks, defined as level 1 tasks, but the invention is not so limited. The “Task level” pull-down menu 1908 can be utilized by a managing project participant to assist in assigning levels (e.g., levels 1 through 3 of
Task scheduler form 2000 further includes pull-down menus, that is, “Major Task List” menu 2006 and “Task Level” menu 2008. These pull-down menus are used similarly to menus 1906 and 1908 of
Task scheduler form 2000 further includes several columns related to development project task performance and completion, which include data entry fields for entering and viewing the respective schedule dates for the tasks. The date columns include “Planned date” column 2010 (equivalent to “Identified Date” of
Use of on-line task scheduler form 2000 operates upon the task objects that define the tasks. For any task, entering data in any of the columns 2002 and 2010-2018 creates or changes the state of the task object that defines the particular task. For example, entering or changing data in column 2002 affects the state of the task name 1702 attribute (
Method of Updating Task Schedule Data
Thus, for any given task, upon an action that triggers the update process for a project task schedule (such as management schedule 1400 of
If the response at step 2102 is positive, that is, the given task does have lower-level tasks in the defined task hierarchy, then at step 2106 it is determined whether the triggering action was an addition of a lower-level task. If the response to step 2106 is negative, then at step 2108 it is determined whether the triggering action was a change to a “planned” date (i.e., planned start or planned end) of the task schedule 1704 data (
If the response to step 2112 is positive, then at step 2126 the latest actual end date from the lower-level tasks is retrieved and stored in the data structure of the given task. For example, the vector of lower-level references 1706 (
Returning to step 2110, if the response to step 2110 is positive (i.e., the actual start date of a lower-level task has been updated, which is the triggering event), then at step 2124 the earliest actual start date from the lower-level tasks of the given task are retrieved and stored in the data structure of the given task. According to step 2124, the task schedule 1704 (
Returning to step 2108, if the response to step 2108 is positive (i.e., the planned start or end date of a lower-level task has been updated, which is the triggering event), then the process moves to step 2116, whereby the current data is moved to the vector of history 1710 (
Returning to step 2106, if the response at step 2106 is positive (i.e., a lower-level task has been added and associated with the given task), then at step 2116 the current data is moved to the vector of history 1710 (
At step 2120, the earliest planned start date from the lower-level tasks (which includes the triggering task) is retrieved and stored in the data structure of the given task. According to step 2120, the task schedule 1704 (
Alternately, the logic of
Returning to the method as depicted in
Throughout the process depicted in
Software Design Specification
Returning to
At block 2206, after passing the inspection of block 2204, the design specification document is registered, internal to the organization, as an official document. As an official document, the design specification is controlled through a document control system. Further, the design specification document may be a part of a larger software specification document. Finally, at block 2208, at the appropriate time a software coder implements the design specified in the design specification. To that end, the coder typically codes and tests the software.
Design Specification Verification Tool
Variable checker 2302 is configured to automatically check the class attribute names in the Function Definitions section of a class specification against the class attribute names described in the Class Attribute section of the class specification. Referring to Appendix A for an example, variable checker 2302 finds class attribute names listed in the Function Definitions section A007 of the class specification A001 and compares them with the class attribute names described in the Class Attributes section A006 of the same class specification A001.
Variable checker 2302 is further configured to automatically check the function parameter names in the Function Definitions section of a class specification against the function parameter names in the Function List section of the same class specification. Referring to Appendix A for an example, variable checker 2302 finds function parameter names included in the Function Definitions section A007 section of the class specification A001 and compares the parameter names with the function parameter names declared in the Function List A004 of the same class specification A001.
In one embodiment, variable checker 2302 is further configured to locate local variable names referenced in the Function Definitions section. Local variables may be specified in algorithms within the function definitions. If local variable names are specified in a function definition, then these local variables should be named according to organizational rules. However, local variable names are not necessarily used in other sections of the class specification, so once located in the Function Definitions section, there is no other section with which to check the local variable name. Hence, if a local variable name is found only once in a given algorithm in a function definition, then there exists the possibility that the variable is incorrectly spelled somewhere else within the given algorithm. Although not conclusive, a single occurrence of a local variable name within an algorithm of a function definition can mean that there might be an error in the class specification, so single occurrences of local variable names are reported. Therefore, a user is alerted to the possibility of an error and can research the issue further.
With respect to checks relating to class attribute names and function parameter names, verification tool 512 reports a discrepancy if one is found. For example, reporter 2306 of verification tool 512 can report any discrepancies with respect to the design specification being verified by saving data representing the problem in local or shared memory, by displaying an indication of the problem, by printing an indication of the problem, or by any combination of these. Furthermore, in the embodiment in which local variable occurrences are verified, reporter 2306 can report single occurrences of local variables in any of the same manners. In one embodiment, the information used in reporting discrepancies includes the number of times that a given attribute or parameter is used in a respective function.
Rules 2304 includes documentation rules with respect to organizational naming conventions regarding, for example, class attribute names, function parameter names, structure names and local variable names. For example, in one embodiment, attribute names are prefixed with “m_”, function parameters are prefixed with either “in_”, “out_”, or “inOut_”, and local variable names are prefixed with “loc_”. Rules 2304 are not limited to the number or type of rules described above, for rules 2304 can be implemented to include any number of organizational constraints relating to design specification generation, that is, naming rules or otherwise. Other conventions embodied in rules 2304 may be used to verify other elements of a design specification.
Rules 2304 are used by the variable checker 2302 to check the design specification document or file. The naming conventions embodied in rules 2304 are used to locate applicable elements, for example, class attributes names, function parameter names and local variable names, within the different sections of the class specification so that the elements can be compared to occurrences in other sections of the class specification. For example, once a type of element of interest is located in the Function List or Class Attribute sections based on rules 2304, for example, via naming prefixes associated with respective element types, the Function Definitions section is searched for a corresponding element. This search can entail a complete element name or part of an element name found in the respective section, rather than just the applicable prefix. Thus, misspelled occurrences of corresponding elements are likely to be found more readily.
Implementations of these teachings may vary. For example, elements may first be located in the Function Definition section and then searched for and verified with corresponding elements in the Function List, Defined Type List and Class Attributes sections.
Optional naming rule enforcer 2308 of verification tool 512 is a module that can enforce naming rules on occurrences of elements within the class specification A001 of a design specification. For example, when discrepancies are discovered within the various sections of the class specification, naming rule enforcer 2308 is configured to reconcile the discrepancies by re-naming the misspelled elements according to the rules. Rules 2304 is referenced by naming rule enforcer 2308 in the course of enforcing the naming conventions. Furthermore, verification tool 512 can be configured with other similarly functioning rule enforcers in addition to or instead of naming rule enforcer 2308, whereby any number of other rules or organizational conventions can be enforced upon-the design specification document.
Optional class reconciler 2310 of verification tool 512 is a module that can reconcile usage of elements, e.g., class attribute names and function parameter names, among different classes of the software application. After a first class (represented by a class specification of a design specification) is processed by verification tool 512, subsequent verification of other class specifications can use the knowledge obtained in verifying and reconciling the first class. Thus, consistency among different classes represented by different corresponding class specifications is ensured with respect to referenced class attributes and function parameters. If the functionality of verification tool 512 is expanded to include verification of elements other than those discussed herein, which is specifically contemplated, then the functionality of class reconciler 2310 can expanded accordingly in order to reconcile the other elements among the various class specifications.
In one embodiment, class reconciler 2310 is configured to reconcile elements among a parent class and any associated derived classes. Hence, verification of a derived class is benefited by employing knowledge gained in verifying the parent class.
Class Specification
Appendix A is an example of a class specification A001 with all the components required by the corresponding document rule(s): Title A002, Base Class A003, Function List A004, Defined Type List A005, Class Attributes A006, and Function Definitions A007. The class specification provides enough information to generate the code for the class. Appendix B is an example of an incorrectly formatted class specification B001. Appendix C is an example of a class specification C001 with undeclared functions and undeclared variables used by the functions. Further references are made hereafter to Appendix A, Appendix B, and Appendix C.
Various computer programming terminology is used herein in the context of a class specification, with general definitions as follow. In object-oriented programming, a class is a user-defined type consisting of methods (i.e., member functions of the class) and variables (i.e., attribute members of the class). The class is a template definition of a particular kind of object. An object is a specific instance of a class, where the variables contain real values. A parameter is an item of information that is passed to a program or function by a user or another program, and affects the operation of the program or function receiving the parameter. Therefore, parameters are a type of variable and can be used in the context of functions. Generally, a variable declared as ‘local’ is a variable that is visible only within the block of code in which the local variable appears and, thus, the local variable has local scope. In a function, a local variable has meaning only within that function block. Whereas the attribute members of a class are private by default (i.e., members are accessible only within the class), structures (or “struct”) are similar to classes but in which attribute members are public by default. Structures contain member functions and attribute members just like classes. However, the attribute members are accessible outside the structure.
A Function List section A004 typically includes function declarations of the particular class described in the class specification. In the example class specification A001 of Appendix A, a class named “CHTMLProcessor” is specified. Furthermore, the Function List A004 includes parameters associated with the functions declared in Function List A004. In one implementation, parameters of the functions are prefixed with either “in_”, “out_”, or “inOut_”, depending on how the parameters are used in the respective function. Although the preceding prefixes are presented as an example, the significance of organizational rules and required addendums associated with parameter naming is described further below.
In addition, enumerations, structures, and nested classes might also be defined in a Defined Type List section A005. For example, enumeration A010 illustrates an enumeration type named “ELineStatus”, structure A011 illustrates a structure named “SExtractionState”, and class A012 illustrates a nested class named “CLineOfFile”.
The Class Attributes section A006 lists and defines the attribute members of the particular class described in the class specification, e.g., CHTMLProcessor. In one implementation, attribute names are prefixed with “m_”. Although the preceding prefix is presented as an example, the significance of organizational rules and required addendums associated with class attribute naming is described further below.
The Function Definitions section A007 defines the algorithms used to implement the functions that are associated with the particular class described in the class specification, e.g., CHTMLProcessor. Function parameters and class attributes are used in the function definitions in the Function Definitions section A007 of class specification A001.
In addition, local variables used in a function definition may be specified in an associated algorithm of the function definition. In one implementation, local variable names are prefixed with “loc_”. Although the preceding prefix is presented as an example, the significance of organizational rules and required addendums associated with local variable naming is described further below.
Process for Validating a Design Specification Document
Process 2400 is embodied in computer software code and, thus, is an automated validation process. Process 2400 depicts a specific implementation of the embodiments described herein and, therefore, some steps can be added or deleted from process 2400 and the resulting process still falls within the scope of the broader teachings herein. Further, process 2400 may be carried out by verification tool 512 (
According to one embodiment, the validator performs two passes through the file to validate the class specification. During the first pass, the validator determines if the file corresponds to a class specification, at block 2404. If the file does not correspond to a class specification, then the validator displays a message on the web page indicating that the file does not correspond to a class specification, at block 2406. If the file is a class specification file, then the validator continues processing the class specification file based upon corresponding documentation rules, at block 2408.
At block 2410, it is determined whether the class specification is in the correct format, i.e., whether the class specification file contains all the components in the right order, such as with class specification A001 of Appendix A. If the class specification file is not in the correct format, such as with class specification B001 of Appendix B (which is missing a Defined Type List section), then the validator displays a message on the web page identifying the missing components of the class specification.
Processing The Function List Section
In the second pass through the class specification file, the validator locates the Function List section (e.g., A004 of Appendix A) of the class specification, and processes the Function List as follows, at block 2414. From the Function List, the validator obtains and maintains each function name along with an associated parameter listing. For example, the validator extracts the function names and associated parameter listings from Function List section of the class specification file and stores this information in volatile memory, e.g., RAM.
With reference to the sample class specification A001 of Appendix A, the validator would extract the function names (public: CHTMLProcessor, ˜CHTMLProcessor, obtainDataFromHTMLFile; private: setupExtractionStateVector, adjustMap, obtainNonBlankLine, obtainNonBlankLine, clear) and associated parameter listings (in_HPPTSession for CHTMLProcessor function; inOut_Status and in_KeyValueInfoVector for obtainDataFromHTMLFile function; in_KeyValueInfoVector for setupExtractionStateVector function; inOut_Status and in_sValue and in_InfoType and in_nRelativePriority for adjustMap function; out_sLine for first obtainNonBlankLine function; out_sLine and in_sLine for second obtainNonBlankLine function; out_sLine for clear function) from the Function List section A004.
By maintaining the function name with its associated parameter listing, the validator can distinguish between overloaded functions in which the respective function names are the same but the respective associated parameter listings differ. With reference to the sample class specification A001 of Appendix A, the validator would distinguish between the first and second obtainNonBlankLine functions from Function List A004. Knowledge of such differences is used for validating functions and variables in the Function Definitions section (e.g., A007 of Appendix A) of the class specification, as described hereafter in reference to block 2420. Encountering the Defined Type List section (e.g., A005 of Appendix A) of the class specification is an indication that all the functions of the class specified in the class specification have been obtained by the validator.
Processing the Defined Type List Section
The Defined Type List section of a class specification contains the enumerations, structures, and classes that are defined within a class. According to one embodiment, the validator processes the structures and classes that are in the Defined Type List (e.g., A005 of Appendix A) as follows, at block 2416. For each structure and class, the corresponding attributes and functions are obtained and maintained. For example, the validator extracts the attribute names and function names from the Defined Type List section of the class specification file and stores this information in volatile memory, e.g., RAM.
According to one embodiment, the attributes of the defined types are identified by the leading “m_”; however, the manner in which the attributes of the defined types are identified may vary from implementation to implementation. With reference to the sample class specification A001 of Appendix A, the validator would extract the attribute names (m_LineState, m_currentPreconditionltr, m_Endltr, m_infoType, m_nRelativePriority, m_sFrontDelete1, m_sFrontDelete2, m_sBackDelete for structure SExtractionState; m_sLine for nested class CLineOfFile) and function names (SExtractionState, ˜SExtractionState, clear for structure SExtractionState; CLineOfFile, ˜CLineOfFile, processLineOfFile for nested class CLineOfFile) from the Defined Type List section A005. Thus, the validator is capable of recognizing and handling nested classes (e.g., CLineOfFile) and structures (e.g., SExtractionState) that are defined within a class (e.g., CHTMLProcesor) of a class specification, such as in a Defined Type List section of a class specification, to validate the nested classes and structures against other sections of the class specification document, as described in greater detail hereafter.
The names of the structure or class are prefixed to the corresponding function names, which are associated with each function's parameter listing, to indicate that the function corresponds to the structure or class. For example, the structure name “SExtractionState” would be prefixed to the function “clear” to form a unique name, “SExtractionState::clear”, indicating that the “clear” function corresponds to the “SExtractionState” structure. For another example, the class name “CLineOfFile” would be prefixed to the function “processLineOfFile” to form a unique name, “CLineOfFile::processLineOfFile”, indicating that the “processLineOfFile” function corresponds to the “CLineOfFile” class. The function name prefix and the associated function parameter listings are used to distinguish the functions of the class from the functions of the defined types (e.g., structures and nested classes), as well as to distinguish between overloaded functions within the defined types. Encountering the Class Attributes section of the class specification is an indication that all the classes and structures of the defined type list have been obtained by the validator.
Processing the Class Attributes Section
The Class Attributes section (e.g., A006 of Appendix A) of a class specification contains all the attribute members of a class. As mentioned, the attributes of the class are identified by the leading “m_”, according to one embodiment. According to one embodiment, the validator processes the class attributes that are in the Class Attibutes section as follows, at block 2418. The validator obtains and maintains all attributes of the class. For example, the validator extracts the attributes from the Class Attributes section of the class specification file and stores this information in volatile memory, e.g., RAM. With reference to the sample class specification A001 of Appendix A, the validator would extract the attribute names (m_HTTPSession, m_ExtractValueFromLine, m_ExtractionStateVector, m_nCounter) from the Class Attributes section A006. Encountering the Function Definitions section of the class specification is an indication that all the attributes of a class have been obtained by the validator.
Processing the Function Definitions Section
The Function Definitions section (e.g., A007 of Appendix A) of a class specification contains the description and the algorithm of all the functions of the class and of the defined types (i.e., the structure and classes within the class). According to one embodiment, the validator processes the function definitions that are in the Function Definitions section as follows, at block 2420. For each function defined in the Function Definitions section, the names of the variables (i.e., the parameters) corresponding to the function are obtained and maintained. For example, the validator extracts the function parameter names from the Function Definitions section of the class specification file and stores this information in volatile memory in association with the corresponding function. The parameters of the function are obtained from the function name with parameter listing in the first line (following “Function:”) in the function definition of each function.
Processing Class Attribute and Parameter Variables
According to one embodiment, the names of the parameters are identified by a leading “in_” “inOut_”, or “out_”. As the validator processes the entire definition of a function (i.e., for attributes and function parameters), the validator locates all the variables with leading “m_” (e.g., indicating an attribute type of variable), “in_”, “inOut_”, or “out_” (e.g., indicating a parameter type of variable). If any variables do not correspond to the names of the attributes of the class or of the defined types, or do not correspond to the names of parameters, then a possible undeclared variable is identified and maintained by the validator.
With reference to the sample class specification A001 of Appendix A, the validator would extract the function parameter names (e.g., the parameters in_HTTPSession for the CHTMLProcessor function; in_KeyValuelnfoVector for the setupExtractionStateVector function; inOutStatus and in_sValue and in_InfoType and in_nRelativePriority for adjustMap function; and so on) and attribute names (e.g., the attributes m_HTTPSession for the CHTMLProcessor function; m_ExtractionStateVector and m_PreconditionVector and m_LineState and m_CurrentPreconditionltr and m_Endltr and m_nCounter for the setupExtractionStateVector function; and so on) from the Function Definitions section A007 for each function following the function name with its parameter listing.
Processing Function Local Variables
The validator identifies all the local variables which, according to one embodiment, have a leading “loc_”. The validator maintains the number of times each local variable is used in the definition of the function in the Function Definition section of the class specification. With reference to the sample class specification A001 of Appendix A, the validator would extract the local variables (loc_Pair used four times in adjustMap function; loc_fRemoveTrailing used two times and loc_fRemoveLeading used two times in first obtainNonBlankLine function; and so on) from the Function Definitions section A007.
Processing Function Declarations
As part of processing a definition of a function from the Function Definitions section of the class specification, the validator determines whether the function corresponds to one of the functions identified from the Function List or from the Defined Type List. If the function does not correspond to one of the functions identified from the Function List or from the Defined Type List, then a message is displayed on the web page indicating the function has not been declared. Otherwise the function name is displayed on the web page.
Processing Class Variable Declarations
If a function definition contains any undeclared variables, then a message is displayed which lists all the undeclared variables and the number of times each undeclared variable is used in the function, at block 2422. In this example, while processing the Function Definitions section C007 of the CHTMLProcessor class specification C001 of Appendix C, the validator determines that there is a variable, m_Counter C014, that is referenced in the obtainDataFromHTMLFile function C013 in the Function Definitions section C007. However, the m_Counter C014 variable is not specified in any other section of class specification C001, such as the Defined Type List section C005 or Class Attributes section C006. In response to this determination, the validator displays a message 2908 on the web page illustrated in
A similar table is used to store the parameters listed in a function declaration. According to one embodiment, the key to the parameters lookup table is the parameter names starting with “in_”, “inOut_”, and “out_”. When the validator processes a function definition for a given function declaration and discovers a variable name starting with “in_”, “inOut_”, and “out_”, the validator checks the parameters lookup table to determine whether or not the variable name is in the parameters lookup table and is properly specified. If the variable is not in the parameters lookup table, then the variable has an incorrect parameter name. According to one embodiment, the parameters lookup table is a hash table. However, the type of lookup table used for processing parameter names may vary from implementation to implementation
Processing Use of Local Variables
Furthermore, all the local variables of the function and the number of times each local variable is used are displayed, at block 2422. In this example, while processing the Function Definitions section C007 of the CHTMLProcessor class specification C001 of Appendix C, the validator determines that there are local variables loc_sLine, loc_Line, loc_sValue, and loc_bReturn that are referenced in the obtainDataFromHTMLFile function C013 in the Function Definitions section C007. In response to this determination, the validator displays a local variable list 2914 on the web page illustrated in
The validator processes each function definition defined in the Function Definitions section in turn, and displays the appropriate foregoing message(s) for each function processed. The validator is finished executing once all the function definitions in the Function Definitions section have been processed.
A lookup table similar to lookup table 2504 (
As discussed,
Hence, the foregoing detailed description describes techniques for automated validation of a software class specification. In addition, in this disclosure, certain process steps are set forth in a particular order, and alphabetic and alphanumeric labels are used to identify certain steps. Unless specifically stated in the disclosure, embodiments of the invention are not limited to any particular order of carrying out such steps. In particular, the labels are used merely for convenient identification of steps, and are not intended to imply, specify or require a particular order of carrying out such steps.
In the foregoing specification, the invention has been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.
This application is a continuation-in-part of U.S. patent application Ser. No. 10/313,158, filed Dec. 6, 2002 now U.S. Pat. No. 7,171,652 entitled “Software Development Environment With Design Specification Verification Tool”, which is related to U.S. patent application Ser. No. 09/881,250, entitled “Automated Management Of Development Project Files Over A Network”, and U.S. patent application Ser. No. 10/059,694, entitled “Project Management Over A Network With Automated Task Schedule Update”, the content of all of which is incorporated by reference in its entirety for all purposes as if fully set forth herein.
| Number | Name | Date | Kind |
|---|---|---|---|
| 4819233 | Delucia et al. | Apr 1989 | A |
| 4875162 | Ferriter et al. | Oct 1989 | A |
| 5197001 | Mukherjee | Mar 1993 | A |
| 5490097 | Swenson et al. | Feb 1996 | A |
| 5537541 | Wibecan | Jul 1996 | A |
| 5548506 | Srinivasan | Aug 1996 | A |
| 5603020 | Hashimoto et al. | Feb 1997 | A |
| 5699310 | Garloff et al. | Dec 1997 | A |
| 5709410 | Reeves, Jr. | Jan 1998 | A |
| 5765140 | Knudson et al. | Jun 1998 | A |
| 5826086 | Arima et al. | Oct 1998 | A |
| 5826252 | Wolters, Jr. et al. | Oct 1998 | A |
| 5909689 | Van Ryzin | Jun 1999 | A |
| 6101481 | Miller | Aug 2000 | A |
| 6161113 | Mora et al. | Dec 2000 | A |
| 6189009 | Stratigos et al. | Feb 2001 | B1 |
| 6236409 | Hartman | May 2001 | B1 |
| 6308164 | Nummelin et al. | Oct 2001 | B1 |
| 6351734 | Lautzenheiser et al. | Feb 2002 | B1 |
| 6385765 | Cleaveland et al. | May 2002 | B1 |
| 6405361 | Broy et al. | Jun 2002 | B1 |
| 6581040 | Wright et al. | Jun 2003 | B1 |
| 6609200 | Anderson et al. | Aug 2003 | B2 |
| 6678698 | Fredell et al. | Jan 2004 | B2 |
| 6842760 | Dorgan et al. | Jan 2005 | B1 |
| 6859768 | Wakelam et al. | Feb 2005 | B1 |
| 6895382 | Srinivasan et al. | May 2005 | B1 |
| 6901579 | Suguta | May 2005 | B1 |
| 6957189 | Poage et al. | Oct 2005 | B2 |
| 7107268 | Zawadzki et al. | Sep 2006 | B1 |
| 7299408 | Daconta et al. | Nov 2007 | B1 |
| 7509687 | Ofek et al. | Mar 2009 | B2 |
| 20020046394 | Do et al. | Apr 2002 | A1 |
| 20030200531 | Fairweather | Oct 2003 | A1 |
| 20040162750 | Motoyama | Aug 2004 | A1 |
| 20050044295 | Wakeam et al. | Feb 2005 | A1 |
| 20050060317 | Lott et al. | Mar 2005 | A1 |
| 20060053043 | Clarke | Mar 2006 | A1 |
| Number | Date | Country |
|---|---|---|
| 04-195222 | Jul 1992 | JP |
| 04-250530 | Sep 1992 | JP |
| WO 9849640 | Nov 1998 | WO |
| WO 9904370 | Jan 1999 | WO |
| Number | Date | Country | |
|---|---|---|---|
| 20060265690 A1 | Nov 2006 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 10313158 | Dec 2002 | US |
| Child | 11494912 | US |
