US7634766B2 - Method and apparatus for pattern-based system design analysis using a meta model - Google Patents

Method and apparatus for pattern-based system design analysis using a meta model Download PDF

Info

Publication number
US7634766B2
US7634766B2 US11/134,021 US13402105A US7634766B2 US 7634766 B2 US7634766 B2 US 7634766B2 US 13402105 A US13402105 A US 13402105A US 7634766 B2 US7634766 B2 US 7634766B2
Authority
US
United States
Prior art keywords
model
query
store
meta
target system
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active, expires
Application number
US11/134,021
Other versions
US20060265699A1 (en
Inventor
Syed M. Ali
Yury Kamen
Deepak Alur
John P. Crupi
Daniel B. Malks
Michael W. Godfrey
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Oracle America Inc
Original Assignee
Sun Microsystems Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sun Microsystems Inc filed Critical Sun Microsystems Inc
Priority to US11/134,021 priority Critical patent/US7634766B2/en
Priority to PCT/US2005/018003 priority patent/WO2006126989A1/en
Assigned to SUN MICROSYSTEMS, INC. reassignment SUN MICROSYSTEMS, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: GODFREY, MICHAEL W., ALI, SYED M., ALUR, DEEPAK, CRUPI, JOHN P., MALKS, DANIEL B., KAMEN, YURY
Publication of US20060265699A1 publication Critical patent/US20060265699A1/en
Application granted granted Critical
Publication of US7634766B2 publication Critical patent/US7634766B2/en
Assigned to Oracle America, Inc. reassignment Oracle America, Inc. MERGER AND CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: Oracle America, Inc., ORACLE USA, INC., SUN MICROSYSTEMS, INC.
Active legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3604Software analysis for verifying properties of programs
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/70Software maintenance or management
    • G06F8/74Reverse engineering; Extracting design information from source code

Definitions

  • the present application contains subject matter that may be related to the subject matter in the following U.S. applications filed on May 20, 2005, and assigned to the assignee of the present application: “Method and Apparatus for Tracking Changes in a System” Ser. No. 11/133,831; “Method and Apparatus for Transparent Invocation of a Characteristics Extractor for Pattern-Based System Design Analysis” Ser. No. 11/134,154; “Method and Apparatus for Generating Components for Pattern-Based System Design Analysis Using a Characteristics Model” Ser. No. 11/133,717; “Method and Apparatus for Pattern-Based System Design Analysis” Ser. No.
  • One common type of quality management tool is used to analyze the source code of the software application to identify errors (or potential errors) in the source code.
  • This type of quality management tool typically includes functionality to parse the source code written in a specific programming language (e.g., JavaTM, C++, etc.) to determine whether the source code satisfies one or more coding rules (i.e., rules that define how source code in the particular language should be written).
  • coding rules i.e., rules that define how source code in the particular language should be written.
  • Some quality management tools of the aforementioned type have been augmented to also identify various coding constructs that may result in security or reliability issues. While the aforementioned type of quality management tools corrects coding errors, it does not provide the software developer with any functionality to verify the quality of the architecture of software application.
  • quality management tools of the aforementioned type have been augmented to verify that software patterns have been properly implemented. Specifically, some quality management tools of the aforementioned type have been augmented to allow the software developer to indicate, in the source code, the type of software pattern the developer is using. Then the quality management tool verifies, during compile time, that the software pattern was used/implemented correctly.
  • the source code of the software is parsed and the components (e.g., classes, interfaces, etc.) extracted from the parsing are subsequently combined in a relational graph (i.e., a graph linking all (or sub-sets) of the components).
  • a relational graph i.e., a graph linking all (or sub-sets) of the components.
  • the software developer generates an architectural design, and then compares the architectural design to the relational graph to determine whether the software application conforms to the architectural pattern. While the aforementioned type of quality management tool enables the software developer to view the relationships present in the software application, it does not provide the software developer with any functionality to conduct independent analysis on the extracted components.
  • Another common type of quality management tool includes functionality to extract facts (i.e., relationships between components (classes, interfaces, etc.) in the software) and subsequently displays the extracted facts to the software developer. While the aforementioned type of quality management tool enables the software developer to view the relationships present in the software application, it does not provide the developer with any functionality to independently query the facts or any functionality to extract information other than facts from the software application.
  • Another common type of quality management tool includes functionality to extract and display various statistics (e.g., number of lines of code, new artifacts added, software packages present, etc.) of the software application to the software developer. While the aforementioned type of quality management tool enables the software developer to view the current state of the software application, it does not provide the developer with any functionality to verify the quality of the architecture of the software application.
  • various statistics e.g., number of lines of code, new artifacts added, software packages present, etc.
  • the invention in general, in one aspect, relates to a A method for analyzing a target system, comprising obtaining a characteristics model, loading the characteristics model into a meta model, obtaining a plurality of characteristics from the target system using a characteristics extractor, wherein each of the plurality of characteristics is associated with the characteristics model, storing each of the plurality of characteristics obtained from the target system in a characteristics store, and analyzing the target system by issuing at least one query to the characteristics store to obtain an analysis result, wherein the issuing the at least one query comprises verifying the at least one query using the meta model.
  • the invention relates to a system for analyzing a target system, comprising a meta model configured to extract and store information about a characteristics model, the target system comprising a plurality of characteristics, at least one characteristics extractor configured to obtain at least one of the plurality of characteristics from the target system, wherein the at least one of the plurality of characteristics is defined in the characteristics model, a characteristics store configured to store the at least one of the plurality of characteristics obtained from the target system, and a query engine configured to analyze the target system by issuing at least one query to the characteristics store and configured to obtain an analysis result in response to the at least one query, wherein the issuing the at least one query comprises verifying the at least one query using the meta model.
  • the invention relates to a computer readable medium comprising software instructions for analyzing a target system, the software instructions executable on a computer to obtain a characteristics model, load the characteristics model into a meta model, obtain a plurality of characteristics from the target system using a characteristics extractor, wherein each of the plurality of characteristics is associated with the characteristics model, store each of the plurality of characteristics obtained from the target system in a characteristics store, and analyze the target system by issuing at least one query to the characteristics store to obtain an analysis result, wherein the issuing the at least one query comprises verifying the at least one query using the meta model.
  • FIG. 1 shows a system in accordance with one embodiment of the invention.
  • FIG. 2 shows a meta model schema in accordance with one embodiment of the invention.
  • FIG. 3 shows a characteristics model in accordance one embodiment of the invention.
  • FIGS. 4 through 6 show flowcharts in accordance with one embodiment of the invention.
  • FIG. 7 shows a computer system in accordance with one embodiment of the invention.
  • embodiments of the invention relate to a method and apparatus for pattern-based system design analysis. More specifically, embodiments of the invention provide a method and apparatus for using one or more characteristics models, one or more characteristics extractors, a query engine configured to query the characteristics of a target system to analyze the system design, and a meta model configured to load the one or more characteristics models and configured to verify queries used to analyze the characteristics of the target system.
  • Embodiments of the invention provide the software developer with a fully configurable software quality management tool that enables the software developer to extract information about the characteristics of the various artifacts in the target system, and then issue queries to determine specific details about the various artifacts including, but not limited to, information such as: number of artifacts of the specific type present in the target system, relationships between the various artifacts in the target system, the interaction of the various artifacts within the target system, the software patterns that are used within the target system, etc.
  • FIG. 1 shows a system in accordance with one embodiment of the invention.
  • the system includes a target system ( 100 ) (i.e., the system that is to be analyzed) and a number of components used in the analysis of the target system.
  • the target system ( 100 ) may correspond to a system that includes software, hardware, or a combination of software and hardware. More specifically, embodiments of the invention enable a user to analyze specific portions of a system or the entire system. Further, embodiments of the invention enable a user to analyze the target system with respect to a specific domain (discussed below).
  • the target system ( 100 ) may correspond to any system under analysis where the system may correspond to the entire system including software and hardware, or only a portion of the system (e.g., only the hardware portion, only the software portion, a sub-set of the hardware or software portion, or any combination thereof).
  • the system includes the following components to aid in the analysis of the target system: one or more characteristics extractors (e.g., characteristics extractor A ( 102 A), characteristics extractor N ( 102 N)), a characteristics store application programming interface (API) ( 104 ), a characteristics store ( 106 ), one or more characteristics models ( 108 A, 108 N), a meta model ( 109 ), a query engine ( 110 ), and visualization engine ( 112 ).
  • characteristics extractors e.g., characteristics extractor A ( 102 A), characteristics extractor N ( 102 N)
  • API application programming interface
  • each of the characteristics models ( 108 A, 108 N) describes artifacts (i.e., discrete components) in a particular domain.
  • the domain corresponds to any grouping of “related artifacts” (i.e., there is a relationship between the artifacts).
  • each of the characteristics models ( 108 A, 108 N) includes one or more artifacts, one or more relationships describing the interaction between the various artifacts, and one or more characteristics that describe various features of the artifact.
  • FIG. 3 An example of a characteristics model ( 108 A, 108 N) is shown in FIG. 3 .
  • the use of characteristics models ( 108 A, 108 N) enables a user to analyze the target system ( 100 ) with respect to a specific domain. Further, the use of multiple characteristics models ( 108 A, 108 N) allows the user to analyze the target system ( 100 ) across multiple domains. In addition, the use of multiple characteristics models ( 108 A, 108 N) allows the user to analyze the interaction between various domains on the target system ( 100 ).
  • other components in the system do not directly interact with the characteristics models ( 108 A, 108 N). Instead, the other components in the system communicate with the characteristics models ( 108 A, 108 N) through the meta model ( 109 ).
  • the meta model ( 109 ) provides a layer of abstraction between the other components in the system and the characteristics models ( 108 A, 108 N). Thus, the meta model enables the other components in the system to operate without any knowledge of the actual characteristics models ( 108 A, 108 N) currently being used.
  • the meta model ( 109 ) includes functionality to extract specific pieces of information from the characteristics models ( 108 A, 108 N) in the system and store this information in a form that may be used by other components within the system. Further, the meta model ( 109 ) enables characteristics models ( 108 A, 108 N) to be dynamically added and removed from the system (i.e., characteristics models ( 108 A, 108 N) may be “plugged-in” to the system). The structure and functionality of the meta model ( 109 ) is described below in FIG. 2 .
  • the characteristics extractors are used to obtain information about various artifacts (i.e., characteristics) defined in the characteristics models ( 108 A, 108 N).
  • the characteristics models ( 108 A, 108 N) are used to generate the characteristics extractor (e.g., characteristics extractor A ( 102 A), characteristics extractor N ( 102 N)).
  • the characteristics extractors are generated using the characteristics models ( 108 A, 108 N).
  • the characteristics extractor corresponds to an agent loaded on the target system ( 100 ) that is configured to monitor and obtain information about the artifacts in the target system ( 100 ).
  • the characteristics extractor e.g., characteristics extractor A ( 102 A), characteristics extractor N ( 102 N)
  • the characteristics extractor may correspond to a process (or system) configured to obtain information about one or more artifacts in the target system ( 100 ) by monitoring network traffic received by and sent from the target system ( 100 ).
  • the characteristics extractor may correspond to a process (or system) configured to obtain information about one or more artifacts in the target system ( 100 ) by sending requests (e.g., pinging, etc.) for specific pieces of information about artifacts in the target system ( 100 ) to the target system ( 100 ), or alternatively, sending requests to the target system and then extracting information about the artifacts from the responses received from target system ( 100 ).
  • requests e.g., pinging, etc.
  • the characteristics extractor e.g., characteristics extractor A ( 102 A), characteristics extractor N ( 102 N)
  • the characteristics extractor may correspond to a process that is configured to parse the source code and temporarily store the artifacts and characteristics obtained from parsing the source code in an in-memory object graph.
  • each characteristics extractor (or set of characteristics extractors) is associated with a particular characteristics model ( 108 A, 108 N).
  • each characteristics extractor typically only retrieves information about artifacts described in the characteristics model ( 108 A, 108 N) with which the characteristics extractor is associated.
  • each characteristics model ( 108 A, 108 N) may be associated with one or more characteristics extractors.
  • characteristics store API ( 104 ) provides an interface between the various characteristics extractors (characteristics extractor A ( 102 A), characteristics extractor N ( 102 N)) and the characteristics store ( 106 ). Further, the characteristics store API ( 104 ) includes information about where in the characteristics store ( 106 ) each characteristic obtained from the target system ( 100 ) should be stored.
  • the characteristics store ( 106 ) corresponds to any storage that includes functionality to store characteristics in a manner that allows the characteristics to be queried.
  • the characteristics store ( 106 ) may correspond to a persistent storage device (e.g., hard disk, etc).
  • the characteristics store ( 106 ) corresponds to a relational database that may be queried using a query language such as Structure Query Language (SQL). Those skilled in the art will appreciate that any query language may be used.
  • SQL Structure Query Language
  • the characteristics store ( 106 ) is a relational database
  • the characteristics model ( 108 A, 108 N) may be used to generate a schema for storing the characteristics associated with the particular characteristics model ( 108 A, 108 N).
  • each characteristics model ( 108 A, 108 N) within the system may be associated with a separate schema.
  • the characteristics store API ( 104 ) includes the necessary information to place characteristics obtained from target system ( 100 ) in the appropriate tables in the characteristics store ( 106 ).
  • the characteristics store API ( 104 ) may include information about which table in the characteristics store ( 106 ) to place specific pieces of information about artifacts in the target system ( 100 ).
  • the characteristics store API ( 104 ) is generated using the characteristics model ( 108 A, 108 N).
  • the characteristic store API ( 104 ) is configured to populate the characteristics store ( 106 ) using the populated in-memory object graph.
  • characteristics store API ( 104 ) populates the characteristics store ( 106 ) by traversing the in-memory object graph and, for each artifact or characteristic encountered, determining where in the characteristics store ( 106 ) to store the artifact or characteristics, in accordance with the schema generated using the characteristics model with which the artifacts and characteristics are associated.
  • the characteristics store API ( 104 ) includes functionality to search the characteristics store ( 106 ) for the schema associated with the particular artifacts and/or characteristics.
  • the characteristics store ( 106 ) includes a schema
  • the mapping of individual components (e.g., artifacts, characteristics, relationships) in the characteristics models ( 108 A, 108 N) to the various tables within the schema is stored in the corresponding characteristics model ( 108 A, 108 N).
  • the query engine ( 110 ) is configured to issue queries to the characteristics store ( 106 ).
  • the queries issued by the query engine ( 110 ) enable a user (e.g., a system developer, etc.) to analyze the target system ( 100 ).
  • the query engine ( 110 ) is configured to enable the user to analyze the presence of specific software patterns in the target system as well as the interaction between various software patterns in the target system.
  • a software pattern corresponds to a framework that defines how specific components in the target system should be configured (e.g., what types of information each component should manage, what interfaces should each component expose), and how the specific components should communicate with each other (e.g., what data should be communicated to other components, etc.).
  • Software patterns are typically used to address a specific problem in a specific context (i.e., the software/system environment in which the problem arises). Said another way, software patterns may correspond to a software architectural solution that incorporates best practices to solve a specific problem in a specific context.
  • the query engine ( 110 ) may also be configured to issue queries about the interaction of specific software patterns with components that do not belong to a specific software pattern. Further, the query engine ( 110 ) may be configured to issue queries about the interaction of components that do not belong to any software patterns.
  • the query engine ( 110 ) includes functionality to verify the query using the meta model ( 109 ) prior to issuing the query to the characteristics store ( 106 ). The verification of the query using the meta model ( 109 ) is described below in FIG. 6 .
  • the query engine ( 110 ) may include pre-specified queries and/or enable to the user to specify custom queries.
  • both the pre-specified queries and the custom queries are used to identify the presence of one or more software patterns and/or the presence of components that do not belong to a pattern in the target system ( 100 ).
  • the pre-specified queries and the custom queries are specified using a Pattern Query Language (PQL).
  • PQL Pattern Query Language
  • PQL enables the user to query the artifacts and characteristics of the artifacts stored in the characteristics store ( 106 ) to determine the presence of a specific software pattern, specific components of a specific software pattern, and/or other components that are not part of a software pattern, within the target system ( 100 ).
  • the query engine ( 110 ) may include information (or have access to information) about the characteristics model ( 108 A, 108 N) that includes the artifact and/or characteristics being queried. Said another way, if the query engine ( 110 ) is issuing a query about a specific artifact, then the query engine ( 110 ) includes information (or has access to information) about the characteristics model to which the artifact belongs. Those skilled in the art will appreciate that the query engine ( 110 ) only requires information about the particular characteristics model ( 108 A, 108 N) to the extent the information is required to issue the query to the characteristics store ( 106 ).
  • the query engine ( 110 ) may include functionality to translate PQL queries (i.e., queries written in PQL) into queries written in a query language understood by the characteristics store ( 106 ) (e.g., SQL).
  • a query written in PQL may be translated into an SQL query prior to being issued to the characteristics store ( 106 ).
  • the user only needs to understand the artifacts and/or characteristics that the user wishes to search for and how to express the particular search using PQL. The user does not need to be concerned with how the PQL query is handled by the characteristics store ( 106 ).
  • PQL queries may be embedded in a programming language such as JavaTM, Groovy, or any other programming language capable of embedding PQL queries.
  • a user may embed one or more PQL queries into a program written in one of the aforementioned programming languages.
  • the program issues one or more PQL queries embedded within the program and subsequently receives and processes the results prior to displaying them to the user.
  • the processing of the results is performed using functionality of the programming language in which the PQL queries are embedded.
  • the results of the individual PQL queries may be displayed using the visualization engine ( 112 ).
  • the visualization engine ( 112 ) is configured to output the results of the queries on a display device (i.e., monitor, printer, projector, etc.).
  • FIG. 2 shows a meta model schema in accordance with one embodiment of the invention.
  • the function of the meta model ( 109 ) is to provide a layer of abstraction between the components of the system and the characteristics models ( 108 A, 108 N).
  • the meta model ( 109 ) corresponds to a model that stores information that describes characteristics models ( 108 A, 108 N). More specifically, the meta model ( 109 ) stores meta model instances of the characteristics models ( 108 A, 108 N), where each meta model instance of the characteristics model ( 108 A, 108 N) corresponds to the representation of the particular characteristics model within the meta model ( 109 ).
  • the representation of a characteristics model ( 108 A, 108 N) in the meta model is dictated by the meta model schema. An example of a meta model schema shown in FIG. 2 .
  • the meta model schema includes four entities: a meta model entity ( 120 ), a meta attribute entity ( 122 ), a meta characteristics entity ( 124 ), and a meta relationship entity ( 126 ).
  • the meta model entity ( 120 ) represents a characteristics model ( 109 ).
  • the meta model entity ( 120 ) may include zero or more meta attribute entities ( 122 ), where each meta attribute entity ( 122 ) is configured to store a name of an attribute associated with a characteristics model ( 108 A, 108 N).
  • Each meta attribute entity ( 122 ) is associated with zero or more meta characteristics ( 124 ), where each meta characteristics is configured to store a name of a characteristic associated with the attribute stored in the associated meta attribute entity ( 122 ).
  • each meta attribute entity ( 122 ) is also associated with zero or more meta relationships ( 126 ), where each meta relationship ( 126 ) is configured to store a name of relationship associated with the attribute store in the associated meta attribute entity ( 122 ). Exemplary information stored in each of the aforementioned entities is shown in FIG. 2 .
  • the meta model ( 109 ) includes exemplary information as described in the meta model schema shown in FIG. 2 . However, the additional information associated with the particular characteristics model is maintained in the characteristics models ( 108 A, 108 N).
  • meta model schema only describes the organization of the information within the meta model and that the actual implementation of the meta model schema may vary in different implementations.
  • the meta model is implemented as a relational database configured using the meta model schema.
  • the meta model ( 109 ) includes functionality to remove information that corresponds to characteristics models ( 108 A, 108 N) that have been removed from the system. Further, the meta model ( 109 ) may also include functionality to request information from the specific characteristics models ( 108 A, 108 N) (e.g., information about how the specific attributes, characteristics, and relationships are represented in the characteristics store, etc.). The meta model ( 109 ) also includes functionality to traverse and/or search the contents of the meta model to determine the presence of a specific artifact, characteristic, or relationship between artifacts in the system.
  • each characteristics model defines one or more artifacts, one or more relationships between the artifacts, and one or more characteristics for each artifact.
  • the characteristics model corresponds to a formal specification of a domain.
  • the following is an example of a JavaTM characteristics model that is formal specification of a JavaTM language domain in accordance with one embodiment of the invention.
  • the JFactDatabase artifact is defined in lines 1-7
  • the JPackage artifact is defined in lines 9-16
  • the JClass artifact is defined in lines 18-35
  • the JMethod artifact is defined in lines 37-57
  • the JField artifact is defined in lines 59-70
  • the JParameter artifact is defined in lines 72-80.
  • FIG. 3 A graphical representation of the JavaTM characteristics model described above is shown in FIG. 3 . Specifically, FIG.
  • box ( 130 ) corresponds to the JFactDatabase artifact
  • box ( 132 ) corresponds to the JPackage artifact
  • box ( 134 ) corresponds to the JClass artifact
  • box ( 136 ) corresponds to the JField artifact
  • box ( 138 ) corresponds to the JParameter artifact
  • box ( 140 ) corresponds to the JMethod artifact.
  • the characteristics model is used to generate a schema.
  • the following text describes a textual representation of a JavaTM schema generated using the JavaTM characteristics model shown in FIG. 3 .
  • lines 1-11 define the table associated with the JFactDatabase artifact
  • lines 13-24 define the table associated with the JPackage artifact
  • lines 26-45 define the table associated with the JClass artifact
  • lines 47-76 define various join tables used to represent various m:n relationships defined in the JavaTM characteristics model shown in FIG. 3 for the JClass artifact
  • lines 128-147 define the table associated with the JMethod artifact
  • lines 78-126 and 149-157 define various tables used to represent various relationships defined in the JavaTM characteristics mode shown in FIG.
  • lines 158-174 define the table associated with the JField artifact
  • lines 176-188 define the table associated with the JParameter artifact
  • lines 190-247 define additional tables used to implement the JavaTM schema
  • lines 248-315 define the various relationships (e.g., 1:1 and 1:n) between the various artifacts defined in the JavaTM characteristics model.
  • FIG. 4 shows a flowchart in accordance with one embodiment of the invention.
  • a characteristics model is obtained (ST 100 ).
  • the characteristics model is obtained from a predefined set of characteristics models.
  • the characteristics model is a customized characteristics model to analyze a specific domain in the target system and obtained from a source specified by the user.
  • the characteristics model is subsequently loaded into the meta model (ST 102 ).
  • “loading” the characteristics model into the meta model includes extracting specific pieces of information about the characteristics model (such as the information described in the meta model schema shown in FIG. 2 ) and loading the extracted information into the meta model.
  • a schema for the characteristics store is subsequently created and associated with characteristics model (ST 104 ).
  • One or more characteristics extractors associated with characteristics model are subsequently created (ST 106 ).
  • a characteristics store API is created (ST 108 ).
  • creating the characteristics store API includes creating a mapping between characteristics obtained by the characteristics extractors and tables defined by the schema configured to store the characteristics in the characteristics store.
  • ST 100 -ST 108 may be repeated for each characteristics model.
  • the characteristics store API may only need to be modified to support additional schemas in the characteristics data store and additional characteristics extractors.
  • each characteristics model may be associated with a different characteristics store API.
  • FIG. 5 shows a flowchart in accordance with one embodiment of the invention.
  • characteristics are obtained from the target system using one or more characteristics extractors (ST 110 ).
  • the characteristics extractors associated with a given characteristics model only obtain information about characteristics associated with the artifacts defined in the characteristics model.
  • the characteristics obtained from the target system using the characteristics extractors are stored in the characteristics store using the characteristics store API (ST 112 ).
  • the target system may be analyzed using the characteristics model (or models), the query engine, the meta model, and the characteristics stored in the characteristics store (ST 114 ) (describe below in FIG. 6 ).
  • the user uses the query engine to issue queries to characteristics store.
  • the query engine has access, via the meta model, to information about the characteristics models currently being used to analyze the target system.
  • the results of the analysis are subsequently displayed using a visualization engine (ST 116 ).
  • FIG. 6 shows a flowchart in accordance with one embodiment of the invention.
  • a PQL query is received by the query engine (ST 120 ).
  • the PQL query is subsequently verified using the meta model (ST 122 ).
  • verifying the PQL query includes searching the meta model to determine whether each component in the PQL query (i.e., artifact, characteristic, or relationship) is present in the meta model. If the meta model is implemented as a series of tables in accordance with a meta model schema (such as the one shown in FIG. 2 ), then searching the meta model includes searching the various tables in the meta model.
  • a meta model schema such as the one shown in FIG. 2
  • a determination of whether the verification of the PQL query was successful is subsequently made (ST 124 ).
  • the verification of the PQL query is successful if every component in the PQL query is present in the meta model.
  • the meta model When the above query is submitted to the meta model for verification, the meta model first determines whether the “JClass” component is present in the meta model. Assuming that the JavaTM characteristics model (described above) is loaded into the meta model, then the meta model will discover that “JClass” is an artifact. Next, the meta model will attempt to verify whether “c.parentPackage.name” is a valid component. Since “c” is selected from “JClass” (as defined in the query), the component “c.parentPackage.name” may be re-written as “JClass.parentPackage.name.” As defined in the JavaTM characteristics model discussed above, “JClass” is related to “JPackage” through a “parentPackage” relationship. Further, “name” is a characteristic of “JPackage,” thus the component “JClass.parentPackage.name” is a valid component. As there are no other components in the query to verify, the verification of the query is complete and successful.
  • the query engine may request a new or modified PQL query (ST 126 ). If a new or modified PQL query is submitted, then the method proceeds to ST 120 . Alternatively, if a new or modified PQL query is not submitted, then the method ends.
  • the meta model may also issue an error message indicating that the verification was not successful.
  • PQL query is translated into a query understood by the characteristics store using the schema(s) associated with the various components in the PQL query (ST 128 ).
  • the characteristics store may not include functionality to query the characteristics using a PQL query.
  • the PQL query is translated into a query understood by the characteristics store, for example, an SQL query.
  • translating the PQL query into, for example, an SQL query includes obtaining information about how specific components (i.e., artifacts, characteristics, and relationships) are referred to in the characteristics store.
  • the meta model upon successful verification of the PQL query, may query the individual characteristics models to determine how each of the components in the PQL query are represented in the characteristics store (i.e., what table each component is in, what name is used to refer to the component in the characteristics store, etc.).
  • the query resulting from the translation is subsequently issued to the characteristics store (ST 130 ), and the results of the query are then returned to the query engine (ST 132 ).
  • FIG. 6 refers to PQL and SQL queries, other query languages (such as those discussed above) may be used.
  • STI 10 -ST 112 may be performed concurrently with ST 114 -ST 116 .
  • steps in FIG. 4 , FIG. 5 , and FIG. 6 may be performed concurrently.
  • a networked computer system ( 200 ) includes a processor ( 202 ), associated memory ( 204 ), a storage device ( 206 ), and numerous other elements and functionalities typical of today's computers (not shown).
  • the networked computer ( 200 ) may also include input means, such as a keyboard ( 208 ) and a mouse ( 210 ), and output means, such as a monitor ( 212 ).
  • the networked computer system ( 200 ) is connected to a local area network (LAN) or a wide area network via a network interface connection (not shown).
  • LAN local area network
  • network interface connection not shown.
  • one or more elements of the aforementioned computer ( 200 ) may be located at a remote location and connected to the other elements over a network.
  • software instructions to perform embodiments of the invention may be stored on a computer readable medium such as a compact disc (CD), a diskette, a tape, or any other physical computer readable storage device.

Abstract

A method for analyzing a target system that includes obtaining a characteristics model, loading the characteristics model into a meta model, obtaining a plurality of characteristics from the target system using a characteristics extractor, wherein each of the plurality of characteristics is associated with the characteristics model, storing each of the plurality of characteristics obtained from the target system in a characteristics store, and analyzing the target system by issuing at least one query to the characteristics store to obtain an analysis result, wherein the issuing the at least one query comprises verifying the at least one query using the meta model.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS
The present application contains subject matter that may be related to the subject matter in the following U.S. applications filed on May 20, 2005, and assigned to the assignee of the present application: “Method and Apparatus for Tracking Changes in a System” Ser. No. 11/133,831; “Method and Apparatus for Transparent Invocation of a Characteristics Extractor for Pattern-Based System Design Analysis” Ser. No. 11/134,154; “Method and Apparatus for Generating Components for Pattern-Based System Design Analysis Using a Characteristics Model” Ser. No. 11/133,717; “Method and Apparatus for Pattern-Based System Design Analysis” Ser. No. 11/134,062; “Method and Apparatus for Cross-Domain Querying in Pattern-Based System Design Analysis” Ser. No. 11/133,507; “Pattern Query Language” Ser. No. 11/133,660; and “Method and Apparatus for Generating a Characteristics Model for Pattern-Based System Design Analysis Using a Schema” Ser. No. 11/133,714.
BACKGROUND
As software technology has evolved, new programming languages and increased programming language functionality has been provided. The resulting software developed using this evolving software technology has become more complex. The ability to manage the quality of software applications (including design quality and architecture quality) is becoming increasingly more difficult as a direct result of the increasingly complex software. In an effort to manage the quality of software applications, several software development tools and approaches are now available to aid software developers in managing software application quality. The following is a summary of some of the types of quality management tools currently available.
One common type of quality management tool is used to analyze the source code of the software application to identify errors (or potential errors) in the source code. This type of quality management tool typically includes functionality to parse the source code written in a specific programming language (e.g., Java™, C++, etc.) to determine whether the source code satisfies one or more coding rules (i.e., rules that define how source code in the particular language should be written). Some quality management tools of the aforementioned type have been augmented to also identify various coding constructs that may result in security or reliability issues. While the aforementioned type of quality management tools corrects coding errors, it does not provide the software developer with any functionality to verify the quality of the architecture of software application.
Other quality management tools of the aforementioned type have been augmented to verify that software patterns have been properly implemented. Specifically, some quality management tools of the aforementioned type have been augmented to allow the software developer to indicate, in the source code, the type of software pattern the developer is using. Then the quality management tool verifies, during compile time, that the software pattern was used/implemented correctly.
In another implementation of the aforementioned type of quality management tools, the source code of the software is parsed and the components (e.g., classes, interfaces, etc.) extracted from the parsing are subsequently combined in a relational graph (i.e., a graph linking all (or sub-sets) of the components). In a subsequent step, the software developer generates an architectural design, and then compares the architectural design to the relational graph to determine whether the software application conforms to the architectural pattern. While the aforementioned type of quality management tool enables the software developer to view the relationships present in the software application, it does not provide the software developer with any functionality to conduct independent analysis on the extracted components.
Another common type of quality management tool includes functionality to extract facts (i.e., relationships between components (classes, interfaces, etc.) in the software) and subsequently displays the extracted facts to the software developer. While the aforementioned type of quality management tool enables the software developer to view the relationships present in the software application, it does not provide the developer with any functionality to independently query the facts or any functionality to extract information other than facts from the software application.
Another common type of quality management tool includes functionality to extract and display various statistics (e.g., number of lines of code, new artifacts added, software packages present, etc.) of the software application to the software developer. While the aforementioned type of quality management tool enables the software developer to view the current state of the software application, it does not provide the developer with any functionality to verify the quality of the architecture of the software application.
SUMMARY
In general, in one aspect, the invention relates to a A method for analyzing a target system, comprising obtaining a characteristics model, loading the characteristics model into a meta model, obtaining a plurality of characteristics from the target system using a characteristics extractor, wherein each of the plurality of characteristics is associated with the characteristics model, storing each of the plurality of characteristics obtained from the target system in a characteristics store, and analyzing the target system by issuing at least one query to the characteristics store to obtain an analysis result, wherein the issuing the at least one query comprises verifying the at least one query using the meta model.
In general, in one aspect, the invention relates to a system for analyzing a target system, comprising a meta model configured to extract and store information about a characteristics model, the target system comprising a plurality of characteristics, at least one characteristics extractor configured to obtain at least one of the plurality of characteristics from the target system, wherein the at least one of the plurality of characteristics is defined in the characteristics model, a characteristics store configured to store the at least one of the plurality of characteristics obtained from the target system, and a query engine configured to analyze the target system by issuing at least one query to the characteristics store and configured to obtain an analysis result in response to the at least one query, wherein the issuing the at least one query comprises verifying the at least one query using the meta model.
In general, in one aspect, the invention relates to a computer readable medium comprising software instructions for analyzing a target system, the software instructions executable on a computer to obtain a characteristics model, load the characteristics model into a meta model, obtain a plurality of characteristics from the target system using a characteristics extractor, wherein each of the plurality of characteristics is associated with the characteristics model, store each of the plurality of characteristics obtained from the target system in a characteristics store, and analyze the target system by issuing at least one query to the characteristics store to obtain an analysis result, wherein the issuing the at least one query comprises verifying the at least one query using the meta model.
Other aspects of the invention will be apparent from the following description and the appended claims.
BRIEF DESCRIPTION OF DRAWINGS
FIG. 1 shows a system in accordance with one embodiment of the invention.
FIG. 2 shows a meta model schema in accordance with one embodiment of the invention.
FIG. 3 shows a characteristics model in accordance one embodiment of the invention.
FIGS. 4 through 6 show flowcharts in accordance with one embodiment of the invention.
FIG. 7 shows a computer system in accordance with one embodiment of the invention.
DETAILED DESCRIPTION
Exemplary embodiments of the invention will be described with reference to the accompanying drawings. Like items in the drawings are shown with the same reference numbers.
In the exemplary embodiment of the invention, numerous specific details are set forth in order to provide a more thorough understanding of the invention. However, it will be apparent to one of ordinary skill in the art that the invention may be practiced without these specific details. In other instances, well-known features have not been described in detail to avoid obscuring the invention.
In general, embodiments of the invention relate to a method and apparatus for pattern-based system design analysis. More specifically, embodiments of the invention provide a method and apparatus for using one or more characteristics models, one or more characteristics extractors, a query engine configured to query the characteristics of a target system to analyze the system design, and a meta model configured to load the one or more characteristics models and configured to verify queries used to analyze the characteristics of the target system. Embodiments of the invention provide the software developer with a fully configurable software quality management tool that enables the software developer to extract information about the characteristics of the various artifacts in the target system, and then issue queries to determine specific details about the various artifacts including, but not limited to, information such as: number of artifacts of the specific type present in the target system, relationships between the various artifacts in the target system, the interaction of the various artifacts within the target system, the software patterns that are used within the target system, etc.
FIG. 1 shows a system in accordance with one embodiment of the invention. The system includes a target system (100) (i.e., the system that is to be analyzed) and a number of components used in the analysis of the target system. In one embodiment of the invention, the target system (100) may correspond to a system that includes software, hardware, or a combination of software and hardware. More specifically, embodiments of the invention enable a user to analyze specific portions of a system or the entire system. Further, embodiments of the invention enable a user to analyze the target system with respect to a specific domain (discussed below). Accordingly, the target system (100) may correspond to any system under analysis where the system may correspond to the entire system including software and hardware, or only a portion of the system (e.g., only the hardware portion, only the software portion, a sub-set of the hardware or software portion, or any combination thereof).
As shown in FIG. 1, the system includes the following components to aid in the analysis of the target system: one or more characteristics extractors (e.g., characteristics extractor A (102A), characteristics extractor N (102N)), a characteristics store application programming interface (API) (104), a characteristics store (106), one or more characteristics models (108A, 108N), a meta model (109), a query engine (110), and visualization engine (112). Each of these components is described below.
In one embodiment of the system, each of the characteristics models (108A, 108N) describes artifacts (i.e., discrete components) in a particular domain. In one embodiment of the invention, the domain corresponds to any grouping of “related artifacts” (i.e., there is a relationship between the artifacts). Examples of domains include, but are not limited to, a Java™ 2 Enterprise Edition (J2EE) domain (that includes artifacts such as servlets, filters, welcome file, error page, etc.), a networking domain (that includes artifacts such as web server, domain name server, network interface cards, etc), a DTrace domain (that includes artifacts such as network, cpu, process, thread stack, function call, etc.), and Java™ domain (described below). In one embodiment of the invention, each of the characteristics models (108A, 108N) includes one or more artifacts, one or more relationships describing the interaction between the various artifacts, and one or more characteristics that describe various features of the artifact. An example of a characteristics model (108A, 108N) is shown in FIG. 3.
In one embodiment of the invention, the use of characteristics models (108A, 108N) enables a user to analyze the target system (100) with respect to a specific domain. Further, the use of multiple characteristics models (108A, 108N) allows the user to analyze the target system (100) across multiple domains. In addition, the use of multiple characteristics models (108A, 108N) allows the user to analyze the interaction between various domains on the target system (100).
In one embodiment of the invention, other components in the system (e.g., characteristics store (106), characteristics store API (104), query engine (110), etc.) do not directly interact with the characteristics models (108A, 108N). Instead, the other components in the system communicate with the characteristics models (108A, 108N) through the meta model (109). In one embodiment of the invention, the meta model (109) provides a layer of abstraction between the other components in the system and the characteristics models (108A, 108N). Thus, the meta model enables the other components in the system to operate without any knowledge of the actual characteristics models (108A, 108N) currently being used. Thus, the meta model (109) includes functionality to extract specific pieces of information from the characteristics models (108A, 108N) in the system and store this information in a form that may be used by other components within the system. Further, the meta model (109) enables characteristics models (108A, 108N) to be dynamically added and removed from the system (i.e., characteristics models (108A, 108N) may be “plugged-in” to the system). The structure and functionality of the meta model (109) is described below in FIG. 2.
In one embodiment of the invention, the characteristics extractors (e.g., characteristics extractor A (102A), characteristics extractor N (102N)) are used to obtain information about various artifacts (i.e., characteristics) defined in the characteristics models (108A, 108N). In one embodiment of the invention, the characteristics models (108A, 108N) are used to generate the characteristics extractor (e.g., characteristics extractor A (102A), characteristics extractor N (102N)). In one embodiment of the invention, the characteristics extractors (characteristics extractor A (102A), characteristics extractor N (102N)) are generated using the characteristics models (108A, 108N).
In one embodiment of the invention, the characteristics extractor (e.g., characteristics extractor A (102A), characteristics extractor N (102N)) corresponds to an agent loaded on the target system (100) that is configured to monitor and obtain information about the artifacts in the target system (100). Alternatively, the characteristics extractor (e.g., characteristics extractor A (102A), characteristics extractor N (102N)) may correspond to an interface that allows a user to manually input information about one or more artifacts. In another embodiment of the invention, the characteristics extractor (e.g., characteristics extractor A (102A), characteristics extractor N (102N)) may correspond to a process (or system) configured to obtain information about one or more artifacts in the target system (100) by monitoring network traffic received by and sent from the target system (100).
In another embodiment of the invention, the characteristics extractor (e.g., characteristics extractor A (102A), characteristics extractor N (102N)) may correspond to a process (or system) configured to obtain information about one or more artifacts in the target system (100) by sending requests (e.g., pinging, etc.) for specific pieces of information about artifacts in the target system (100) to the target system (100), or alternatively, sending requests to the target system and then extracting information about the artifacts from the responses received from target system (100).
In one embodiment of the invention, if the target system (100) corresponds to source code and the characteristics model (108A, 108N) corresponds to a formal specification of a programming language (e.g., Java™), then the characteristics extractor (e.g., characteristics extractor A (102A), characteristics extractor N (102N)) may correspond to a process that is configured to parse the source code and temporarily store the artifacts and characteristics obtained from parsing the source code in an in-memory object graph.
Those skilled in the art will appreciate that different types of characteristics extractors may be used to obtain information about artifacts in the target system (100). Further, those skilled in the art will appreciate that each characteristics extractor (or set of characteristics extractors) is associated with a particular characteristics model (108A, 108N). Thus, each characteristics extractor typically only retrieves information about artifacts described in the characteristics model (108A, 108N) with which the characteristics extractor is associated. Furthermore, if there are multiple characteristics models (108A, 108N) in the system, then each characteristics model (108A, 108N) may be associated with one or more characteristics extractors.
The information about the various artifacts in the target system (100) obtained by the aforementioned characteristics extractors (characteristics extractor A (102A), characteristics extractor N (102N)) is stored in the characteristics store (106) via the characteristic store API (104). In one embodiment of the invention, characteristics store API (104) provides an interface between the various characteristics extractors (characteristics extractor A (102A), characteristics extractor N (102N)) and the characteristics store (106). Further, the characteristics store API (104) includes information about where in the characteristics store (106) each characteristic obtained from the target system (100) should be stored.
In one embodiment of the invention, the characteristics store (106) corresponds to any storage that includes functionality to store characteristics in a manner that allows the characteristics to be queried. In one embodiment of the invention, the characteristics store (106) may correspond to a persistent storage device (e.g., hard disk, etc). In one embodiment of the invention, the characteristics store (106) corresponds to a relational database that may be queried using a query language such as Structure Query Language (SQL). Those skilled in the art will appreciate that any query language may be used. In one embodiment of the invention, if the characteristics store (106) is a relational database, then the characteristics model (108A, 108N) may be used to generate a schema for storing the characteristics associated with the particular characteristics model (108A, 108N). Those skilled in the art will appreciate that each characteristics model (108A, 108N) within the system may be associated with a separate schema.
In one embodiment of the invention, if the characteristics store (106) is a relational database that includes a schema generated from the characteristics model (108A, 108N), then the characteristics store API (104) includes the necessary information to place characteristics obtained from target system (100) in the appropriate tables in the characteristics store (106). Specifically, the characteristics store API (104) may include information about which table in the characteristics store (106) to place specific pieces of information about artifacts in the target system (100). In one embodiment of the invention, the characteristics store API (104) is generated using the characteristics model (108A, 108N).
In one embodiment of the invention, if the characteristics extractors are configured to temporarily store artifacts and characteristics obtained from the target system in an in-memory object graph, then the characteristic store API (104) is configured to populate the characteristics store (106) using the populated in-memory object graph. In one embodiment of the invention, characteristics store API (104) populates the characteristics store (106) by traversing the in-memory object graph and, for each artifact or characteristic encountered, determining where in the characteristics store (106) to store the artifact or characteristics, in accordance with the schema generated using the characteristics model with which the artifacts and characteristics are associated. In one embodiment of the invention, if the characteristics store (106) includes multiple schemas, then the characteristics store API (104) includes functionality to search the characteristics store (106) for the schema associated with the particular artifacts and/or characteristics.
In one embodiment of the invention, if the characteristics store (106) includes a schema, then the mapping of individual components (e.g., artifacts, characteristics, relationships) in the characteristics models (108A, 108N) to the various tables within the schema is stored in the corresponding characteristics model (108A, 108N).
Continuing with the discussion of FIG. 1, in one embodiment of the invention, the query engine (110) is configured to issue queries to the characteristics store (106). In one embodiment of the invention, the queries issued by the query engine (110) enable a user (e.g., a system developer, etc.) to analyze the target system (100). In particular, in one embodiment of the invention, the query engine (110) is configured to enable the user to analyze the presence of specific software patterns in the target system as well as the interaction between various software patterns in the target system.
In one embodiment of the invention, a software pattern corresponds to a framework that defines how specific components in the target system should be configured (e.g., what types of information each component should manage, what interfaces should each component expose), and how the specific components should communicate with each other (e.g., what data should be communicated to other components, etc.). Software patterns are typically used to address a specific problem in a specific context (i.e., the software/system environment in which the problem arises). Said another way, software patterns may correspond to a software architectural solution that incorporates best practices to solve a specific problem in a specific context.
Continuing with the discussion of FIG. 1, the query engine (110) may also be configured to issue queries about the interaction of specific software patterns with components that do not belong to a specific software pattern. Further, the query engine (110) may be configured to issue queries about the interaction of components that do not belong to any software patterns. In one embodiment of the invention, the query engine (110) includes functionality to verify the query using the meta model (109) prior to issuing the query to the characteristics store (106). The verification of the query using the meta model (109) is described below in FIG. 6.
In one embodiment of the invention, the query engine (110) may include pre-specified queries and/or enable to the user to specify custom queries. In one embodiment of the invention, both the pre-specified queries and the custom queries are used to identify the presence of one or more software patterns and/or the presence of components that do not belong to a pattern in the target system (100). In one embodiment of the invention, the pre-specified queries and the custom queries are specified using a Pattern Query Language (PQL). In one embodiment of the invention, PQL enables the user to query the artifacts and characteristics of the artifacts stored in the characteristics store (106) to determine the presence of a specific software pattern, specific components of a specific software pattern, and/or other components that are not part of a software pattern, within the target system (100).
In one embodiment of the invention, the query engine (110) may include information (or have access to information) about the characteristics model (108A, 108N) that includes the artifact and/or characteristics being queried. Said another way, if the query engine (110) is issuing a query about a specific artifact, then the query engine (110) includes information (or has access to information) about the characteristics model to which the artifact belongs. Those skilled in the art will appreciate that the query engine (110) only requires information about the particular characteristics model (108A, 108N) to the extent the information is required to issue the query to the characteristics store (106).
Those skilled in the art will appreciate that the query engine (110) may include functionality to translate PQL queries (i.e., queries written in PQL) into queries written in a query language understood by the characteristics store (106) (e.g., SQL). Thus, a query written in PQL may be translated into an SQL query prior to being issued to the characteristics store (106). In this manner, the user only needs to understand the artifacts and/or characteristics that the user wishes to search for and how to express the particular search using PQL. The user does not need to be concerned with how the PQL query is handled by the characteristics store (106).
Further, in one or more embodiments of the invention, PQL queries may be embedded in a programming language such as Java™, Groovy, or any other programming language capable of embedding PQL queries. Thus, a user may embed one or more PQL queries into a program written in one of the aforementioned programming languages. Upon execution, the program issues one or more PQL queries embedded within the program and subsequently receives and processes the results prior to displaying them to the user. Those skilled in the art will appreciate that the processing of the results is performed using functionality of the programming language in which the PQL queries are embedded.
In one embodiment of the invention, the results of the individual PQL queries may be displayed using the visualization engine (112). In one embodiment of the invention, the visualization engine (112) is configured to output the results of the queries on a display device (i.e., monitor, printer, projector, etc.).
FIG. 2 shows a meta model schema in accordance with one embodiment of the invention. As discussed above, the function of the meta model (109) is to provide a layer of abstraction between the components of the system and the characteristics models (108A, 108N). In one embodiment of the invention, the meta model (109) corresponds to a model that stores information that describes characteristics models (108A, 108N). More specifically, the meta model (109) stores meta model instances of the characteristics models (108A, 108N), where each meta model instance of the characteristics model (108A, 108N) corresponds to the representation of the particular characteristics model within the meta model (109). In one embodiment of the invention, the representation of a characteristics model (108A, 108N) in the meta model is dictated by the meta model schema. An example of a meta model schema shown in FIG. 2.
As shown in FIG. 2, the meta model schema includes four entities: a meta model entity (120), a meta attribute entity (122), a meta characteristics entity (124), and a meta relationship entity (126). The meta model entity (120) represents a characteristics model (109). The meta model entity (120) may include zero or more meta attribute entities (122), where each meta attribute entity (122) is configured to store a name of an attribute associated with a characteristics model (108A, 108N). Each meta attribute entity (122) is associated with zero or more meta characteristics (124), where each meta characteristics is configured to store a name of a characteristic associated with the attribute stored in the associated meta attribute entity (122). In addition, each meta attribute entity (122) is also associated with zero or more meta relationships (126), where each meta relationship (126) is configured to store a name of relationship associated with the attribute store in the associated meta attribute entity (122). Exemplary information stored in each of the aforementioned entities is shown in FIG. 2.
In one embodiment of the invention, the meta model (109) includes exemplary information as described in the meta model schema shown in FIG. 2. However, the additional information associated with the particular characteristics model is maintained in the characteristics models (108A, 108N).
Those skilled in the art will appreciate that the meta model schema only describes the organization of the information within the meta model and that the actual implementation of the meta model schema may vary in different implementations. In one embodiment of the invention, the meta model is implemented as a relational database configured using the meta model schema.
In addition to extracting and storing information about characteristics models (108A, 108N) within the system, the meta model (109) includes functionality to remove information that corresponds to characteristics models (108A, 108N) that have been removed from the system. Further, the meta model (109) may also include functionality to request information from the specific characteristics models (108A, 108N) (e.g., information about how the specific attributes, characteristics, and relationships are represented in the characteristics store, etc.). The meta model (109) also includes functionality to traverse and/or search the contents of the meta model to determine the presence of a specific artifact, characteristic, or relationship between artifacts in the system.
As discussed above, each characteristics model defines one or more artifacts, one or more relationships between the artifacts, and one or more characteristics for each artifact. In one embodiment of the invention, the characteristics model corresponds to a formal specification of a domain. The following is an example of a Java™ characteristics model that is formal specification of a Java™ language domain in accordance with one embodiment of the invention.
Java ™ Characteristics Model
 1  persistent class JFactDatabase {
 2  long id primary key;
 3  String version;
 4  String name;
 5  String sourceFile;
 6  references JPackage packages(0,n) inverse factDatabase(1,1);
 7  } // class JFactDatabase
 8
 9  persistent class JPackage {
10  long id primary key;
11  String version;
12  String name;
13  String shortName;
14  references JPackage packages (0,n) inverse parentPackage(1,1);
15  references JClass classes (0,n) inverse parentPackage(1,1);
16  } // class JPackage
17
18  persistent class JClass {
19  long id primary key;
20  String version;
21  String name;
22  String shortName;
23  Boolean isStatic;
24  Boolean isFinal;
25  Boolean isInner;
26  String accessibility;
27  String sourceFile;
28  Integer filePosition;
29  references JClass implementsInterfaces(0,n) inverse
   implementingClasses(0,n);
30  references JClass extendsClass(0,1) inverse extendingClasses(0,n);
31  references JClass contains(0,n) inverse containingClass(1,1);
32  references JMethod methods(0,n) inverse parentClass(1,1);
33  references JField fields(0,n) inverse parentClass(1,1);
34  references JAnnotation annotations(0,n) inverse parentClass(1,1);
35  } // class JClass
36
37  persistent class JMethod {
38  long id primary key;
39  String version;
40  String name;
41  String shortName;
42  Boolean isAbstract;
43  Boolean isConstructor;
44  Boolean isStatic;
45  Boolean isFinal;
46  Integer numParams;
47  String accessibility;
48  Integer filePosition;
49  references JClass returnType(1,1) inverse returnedBy(0,n);
50  references JClass throwsExceptions(0,n) inverse thrownBy(0,n);
51  references JClass catchesExceptions(0,n) inverse caughtBy(0,n);
52  references JClass instantiates(0,n) inverse instantiatedBy(0,n);
53  references JMethod calls(0,n) inverse callers(0,n);
54  references JParameter parameters(0,n) inverse method(1,1);
55  references JField usedFields(0,n) inverse usedByMethods(0,n);
56  references JAnnotation annotations(0,n) inverse parentMethod(1,1);
57  } // class JMethod
58
59  persistent class JField {
60  long id primary key;
61  String version;
62  String name;
63  String shortName;
64  Boolean isStatic;
65  Boolean isFinal;
66  String accessibility;
67  Integer filePosition;
68  references JClass type(1,1) inverse typeFields(0,n);
69  references JAnnotation annotations(0,n) inverse parentField(1,1);
70  } // class JField
71
72  persistent class JParameter {
73  long id primary key;
74  String version;
75  String name;
76  String shortName;
77  Integer index;
78  references JClass type(1,1) inverse typeParameters(0,n);
79  references JAnnotation annotations(0,n) inverse
   parentParameter(1,1);
80  } // class JParameter
81
In the above Java™ characteristics model, the JFactDatabase artifact is defined in lines 1-7, the JPackage artifact is defined in lines 9-16, the JClass artifact is defined in lines 18-35, the JMethod artifact is defined in lines 37-57, the JField artifact is defined in lines 59-70, and the JParameter artifact is defined in lines 72-80. A graphical representation of the Java™ characteristics model described above is shown in FIG. 3. Specifically, FIG. 3 shows each of the aforementioned Java™ characteristics model attributes (i.e., JFactDatabase, JPackage, JClass, JField, JParameter, and JMethod) as well as the characteristics associated with each of the aforementioned artifacts and the relationships between the aforementioned artifacts. In particular, box (130) corresponds to the JFactDatabase artifact, box (132) corresponds to the JPackage artifact, box (134) corresponds to the JClass artifact, box (136) corresponds to the JField artifact, box (138) corresponds to the JParameter artifact, and box (140) corresponds to the JMethod artifact.
As discussed above, the characteristics model is used to generate a schema. The following text describes a textual representation of a Java™ schema generated using the Java™ characteristics model shown in FIG. 3.
Java ™ Schema
1 CREATE TABLE JFactDatabase(
2 id INTEGER,
3 version VARCHAR(255),
4 name VARCHAR(255),
5 sourceFile VARCHAR(255),
6 PRIMARY KEY ( id )
7  );
8
9 CREATE UNIQUE INDEX JFactDatabase_PRIMARY_KEY ON JFactDatabase(id);
10 CREATE UNIQUE INDEX JFactDatabase_name ON JFactDatabase(name);
11 COMMIT;
12
13 CREATE TABLE JPackage(
14 id INTEGER,
15 version VARCHAR(255),
16 name VARCHAR(255),
17 shortName VARCHAR(255),
18 factDatabase INTEGER,
19 PRIMARY KEY ( id )
20  );
21
22 CREATE UNIQUE INDEX JPackage_PRIMARY_KEY ON JPackage(id);
23 CREATE UNIQUE INDEX JPackage_name ON JPackage(name);
24 COMMIT;
25
26 CREATE TABLE JClass(
27 id INTEGER,
28 version VARCHAR(255),
29 name VARCHAR(255),
30 shortName VARCHAR(255),
31 isStatic BOOLEAN,
32 isFinal BOOLEAN,
33 isInner BOOLEAN,
34 accessibility VARCHAR(255),
35 sourceFile VARCHAR(255),
36 filePosition INTEGER,
37 parentPackage INTEGER,
38 extendsClass INTEGER,
39 containingClass INTEGER,
40 PRIMARY KEY ( id )
41  );
42
43 CREATE UNIQUE INDEX JClass_PRIMARY_KEY ON JClass(id);
44 CREATE UNIQUE INDEX JClass_name ON JClass(name);
45 COMMIT;
46
47 CREATE TABLE JClass_ImplementsInterfaces( -- JOIN table for m:n relationship
48 implementsInterfaces INTEGER,
49 implementingClasses INTEGER,
50 PRIMARY KEY ( implementsInterfaces,implementingClasses ),
51 KEY(implementsInterfaces), KEY(implementingClasses)
52  );
53
54 CREATE TABLE JClass_ImplementsInterfacesTransitive( -- JOIN table for m:n relationship
55 implementsInterfaces INTEGER,
56 implementingClasses INTEGER,
57 PRIMARY KEY ( implementsInterfaces,implementingClasses ),
58 KEY(implementsInterfaces), KEY(implementingClasses)
59  );
60
61 COMMIT;
62
63 CREATE TABLE JClass_ExtendsClasses( -- JOIN table for m:n relationship
64 extendsClasses INTEGER,
65 extendingClasses INTEGER,
66 PRIMARY KEY ( extendsClasses,extendingClasses ),
67 KEY(extendsClasses), KEY(extendingClasses)
68  );
69
70 CREATE TABLE JClass_ExtendsClassesTransitive( -- JOIN table for m:n relationship
71 extendsClasses INTEGER,
72 extendingClasses INTEGER,
73 PRIMARY KEY ( extendsClasses,extendingClasses ),
74 KEY(extendsClasses), KEY(extendingClasses)
75  );
76 COMMIT;
77
78 CREATE TABLE JMethod_Calls(
79 calls INTEGER,
80 callers INTEGER,
81 filePosition INTEGER,
82 PRIMARY KEY (calls,callers),
83 KEY(calls), KEY(callers)
84  );
85 CREATE TABLE JMethod_CallsTransitive(
86 calls INTEGER,
87 callers INTEGER,
88 filePosition INTEGER,
89 PRIMARY KEY (calls,callers),
90 KEY(calls), KEY(callers)
91  );
92 COMMIT;
93
94 CREATE TABLE JMethod_ThrowsExceptions(
95 throwsExceptions INTEGER,
96 thrownBy INTEGER,
97 filePosition INTEGER,
98 PRIMARY KEY ( throwsExceptions,thrownBy ),
99 KEY(throwsExceptions), KEY(thrownBy)
100  );
101 COMMIT;
102
103 CREATE TABLE JMethod_CatchesExceptions(
104 catchesExceptions INTEGER,
105 caughtBy INTEGER,
106 filePosition INTEGER,
107 PRIMARY KEY ( catchesExceptions,caughtBy ),
108 KEY(catchesExceptions), KEY(caughtBy)
109  );
110 COMMIT;
111 CREATE TABLE JMethod_Instantiates(
112 callingMethod INTEGER,
113 instantiatedClass INTEGER,
114 filePosition INTEGER,
115 PRIMARY KEY ( callingMethod,instantiatedClass ),
116 KEY(callingMethod), KEY(instantiatedClass)
117  );
118
119 CREATE TABLE JMethod_InstantiatesTransitive(
120 callingMethod INTEGER,
121 instantiatedClass INTEGER,
122 filePosition INTEGER,
123 PRIMARY KEY ( callingMethod,instantiatedClass ),
124 KEY(callingMethod), KEY(instantiatedClass)
125  );
126 COMMIT;
127
128 CREATE TABLE JMethod(
129 id INTEGER,
130 version VARCHAR(255),
131 name VARCHAR(255),
132 shortName VARCHAR(255),
133 isAbstract BOOLEAN,
134 isConstructor BOOLEAN,
135 isStatic BOOLEAN,
136 isFinal BOOLEAN,
137 numParams INTEGER,
138 accessibility VARCHAR(255),
139 filePosition INTEGER,
140 parentClass INTEGER,
141 returnType INTEGER,
142 PRIMARY KEY ( id )
143  );
144
145 CREATE UNIQUE INDEX JMethod_PRIMARY_KEY ON JMethod(id);
146 CREATE UNIQUE INDEX JMethod_name ON JMethod(name);
147 COMMIT;
148
149 CREATE TABLE JMethod_UsedFields(
150 usedFields INTEGER,
151 usedByMethods INTEGER,
152 filePosition INTEGER,
153 PRIMARY KEY ( usedFields,usedByMethods ),
154 KEY(usedFields), KEY(usedByMethods)
155  );
156 COMMIT;
157
158 CREATE TABLE JField(
159 id INTEGER,
160 version VARCHAR(255),
161 name VARCHAR(255),
162 shortName VARCHAR(255),
163 isStatic BOOLEAN,
164 isFinal BOOLEAN,
165 accessibility VARCHAR(255),
166 filePosition INTEGER,
167 parentClass INTEGER,
168 type INTEGER,
169 PRIMARY KEY ( id )
170  );
171
172 CREATE UNIQUE INDEX JField_PRIMARY_KEY ON JField(id);
173 CREATE UNIQUE INDEX JField_name ON JField(name);
174 COMMIT;
175
176 CREATE TABLE JParameter(
177 id INTEGER PRIMARY KEY,
178 version VARCHAR(255),
179 name VARCHAR(255),
180 shortName VARCHAR(255),
181 parameterIndex INTEGER,
182 method INTEGER,
183 type INTEGER
184  );
185
186 CREATE UNIQUE INDEX JParameter_PRIMARY_KEY ON JParameter(id);
187 CREATE UNIQUE INDEX JParameter_name ON JParameter(name);
188 COMMIT;
189
190 CREATE TABLE JAnnotation(
191 id INTEGER PRIMARY KEY,
192 version VARCHAR(255),
193 name VARCHAR(255),
194 shortName VARCHAR(255),
195 numArgs INTEGER,
196 parentClass INTEGER,
197 parentMethod INTEGER,
198 parentField INTEGER,
199 parentParameter INTEGER,
200 type INTEGER
201  );
202
203 CREATE UNIQUE INDEX JAnnotation_PRIMARY_KEY ON JAnnotation(id);
204 CREATE UNIQUE INDEX JAnnotation_name ON JAnnotation(name);
205 COMMIT;
206
207 CREATE TABLE JAnnotationArgument(
208 id INTEGER PRIMARY KEY,
209 version VARCHAR(255),
210 name VARCHAR(255),
211 shortName VARCHAR(255),
212 stringValue VARCHAR(10000),
213 annotation INTEGER,
214 type INTEGER
215  );
216
217 CREATE UNIQUE INDEX JAnnotationArgument_PRIMARY_KEY ON
218 JAnnotationArgument(id);
219 CREATE UNIQUE INDEX JAnnotationArgument_name ON JAnnotationArgument(name);
220 COMMIT;
221
222 CREATE TABLE WriteVariable(
223
224 cookie VARCHAR(255),
225 scope INTEGER,
226 name VARCHAR(255),
227 varIndex INTEGER,
228 nodeId DECIMAL(20,0),
229 nodeName VARCHAR(255)
230  );
231
232 COMMIT;
233
234 CREATE TABLE ReadVariable(
235
236 cookie VARCHAR(255),
237 scope INTEGER,
238 name VARCHAR(255),
239 varIndex INTEGER,
240 nodeId DECIMAL(20,0),
241 nodeName VARCHAR(255)
242  );
243
244 CREATE UNIQUE INDEX ReadVariable_PRIMARY_KEY ON
245 ReadVariable(cookie,scope,name,varIndex);
246 COMMIT;
247
248 ALTER TABLE JPackage ADD CONSTRAINT JPackage_factDatabase FOREIGN KEY
249    (factDatabase) REFERENCES JFactDatabase(id);
250 ALTER TABLE JClass ADD CONSTRAINT JClass_parentPackage FOREIGN KEY
251    (parentPackage) REFERENCES JPackage(id);
252 ALTER TABLE JClass ADD CONSTRAINT JClass_extendsClass FOREIGN KEY
253    (extendsClass) REFERENCES JClass(id);
254 ALTER TABLE JClass ADD CONSTRAINT JClass_containingClass FOREIGN KEY
255    (containingClass) REFERENCES JClass(id);
256 ALTER TABLE JClass_ImplementsInterfaces ADD CONSTRAINT
257    JClass_ImplementsInterfaces_fk_for_implementsInterfaces FOREIGN KEY
258    (implementsInterfaces) REFERENCES JClass(id);
259 ALTER TABLE JClass_ImplementsInterfaces ADD CONSTRAINT
260    JClass_ImplementsInterfaces_fk_for_implementingClasses FOREIGN KEY
261    (implementingClasses) REFERENCES JClass(id);
262 ALTER TABLE JClass_ExtendsClasses ADD CONSTRAINT
263    JClass_ExtendsClasses_fk_for_extendsClasses FOREIGN KEY (extendsClasses)
264    REFERENCES JClass(id);
265 ALTER TABLE JClass_ExtendsClasses ADD CONSTRAINT
266    JClass_ExtendsClasses_fk_for_extendingClasses FOREIGN KEY (extendingClasses)
267    REFERENCES JClass(id);
268 ALTER TABLE JMethod_ThrowsExceptions ADD CONSTRAINT
269    JMethod_ThrowsExceptions_fk_for_throwsExceptions FOREIGN KEY
270    (throwsExceptions) REFERENCES JMethod(id);
271 ALTER TABLE JMethod_ThrowsExceptions ADD CONSTRAINT
272    JMethod_ThrowsExceptions_fk_for_thrownBy FOREIGN KEY (thrownBy)
273    REFERENCES JClass(id);
274 ALTER TABLE JMethod_CatchesExceptions ADD CONSTRAINT
275    JMethod_CatchesExceptions_fk_for_catchesExceptions FOREIGN KEY
276    (catchesExceptions) REFERENCES JMethod(id);
277 ALTER TABLE JMethod_CatchesExceptions ADD CONSTRAINT
278    JMethod_CatchesExceptions_fk_for_caughtBy FOREIGN KEY (caughtBy)
279    REFERENCES JClass(id);
280 ALTER TABLE JMethod ADD CONSTRAINT JMethod_parentClass FOREIGN KEY
281    (parentClass) REFERENCES JClass(id);
282 ALTER TABLE JMethod ADD CONSTRAINT JMethod_returnType FOREIGN KEY
283    (returnType) REFERENCES JClass(id);
284 ALTER TABLE JMethod_Calls ADD CONSTRAINT JMethod_Calls_fk_for_calls FOREIGN
285    KEY (calls) REFERENCES JMethod(id);
286 ALTER TABLE JMethod_Calls ADD CONSTRAINT JMethod_Calls_fk_for_callers FOREIGN
287    KEY (callers) REFERENCES JMethod(id);
288 ALTER TABLE JMethod_UsedFields ADD CONSTRAINT
289    JMethod_UsedFields_fk_for_usedFields FOREIGN KEY (usedFields) REFERENCES
290    JMethod(id);
291 ALTER TABLE JMethod_UsedFields ADD CONSTRAINT
292    JMethod_UsedFields_fk_for_usedByMethods FOREIGN KEY (usedByMethods)
293    REFERENCES JField(id);
294 ALTER TABLE JField ADD CONSTRAINT JField_parentClass FOREIGN KEY (parentClass)
295    REFERENCES JClass(id);
296 ALTER TABLE JField ADD CONSTRAINT JField_type FOREIGN KEY (type)
297    REFERENCES JClass(id);
298 ALTER TABLE JParameter ADD CONSTRAINT JParameter_method FOREIGN KEY
299    (method) REFERENCES JMethod(id);
300 ALTER TABLE JParameter ADD CONSTRAINT JParameter_type FOREIGN KEY (type)
301    REFERENCES JClass(id);
302 ALTER TABLE JAnnotation ADD CONSTRAINT JAnnotation_parentClass FOREIGN KEY
303    (parentClass) REFERENCES JClass(id);
304 ALTER TABLE JAnnotation ADD CONSTRAINT JAnnotation_parentMethod FOREIGN KEY
305    (parentMethod) REFERENCES JMethod(id);
306 ALTER TABLE JAnnotation ADD CONSTRAINT JAnnotation_parentField FOREIGN KEY
307    (parentField) REFERENCES JField(id);
308 ALTER TABLE JAnnotation ADD CONSTRAINT JAnnotation_parentParameter FOREIGN
309    KEY (parentParameter) REFERENCES JParameter(id);
310 ALTER TABLE JAnnotation ADD CONSTRAINT JAnnotation_type FOREIGN KEY (type)
311    REFERENCES JClass(id);
312 ALTER TABLE JAnnotationArgument ADD CONSTRAINT JAnnotationArgument_annotation
313    FOREIGN KEY (annotation) REFERENCES JAnnotation(id);
314 ALTER TABLE JAnnotationArgument ADD CONSTRAINT JAnnotationArgument_type
315    FOREIGN KEY (type) REFERENCES JClass(id);
The following describes the various portions of the Java™ Schema: (i) lines 1-11 define the table associated with the JFactDatabase artifact; (ii) lines 13-24 define the table associated with the JPackage artifact; (iii) lines 26-45 define the table associated with the JClass artifact; (iv) lines 47-76 define various join tables used to represent various m:n relationships defined in the Java™ characteristics model shown in FIG. 3 for the JClass artifact; (v) lines 128-147 define the table associated with the JMethod artifact; (vi) lines 78-126 and 149-157 define various tables used to represent various relationships defined in the Java™ characteristics mode shown in FIG. 3 for the JMethod artifact; (vii) lines 158-174 define the table associated with the JField artifact; (viii) lines 176-188 define the table associated with the JParameter artifact; (ix) lines 190-247 define additional tables used to implement the Java™ schema; (x) lines 248-315 define the various relationships (e.g., 1:1 and 1:n) between the various artifacts defined in the Java™ characteristics model.
FIG. 4 shows a flowchart in accordance with one embodiment of the invention. Initially, a characteristics model is obtained (ST100). In one embodiment of the invention, the characteristics model is obtained from a predefined set of characteristics models. Alternatively, the characteristics model is a customized characteristics model to analyze a specific domain in the target system and obtained from a source specified by the user. The characteristics model is subsequently loaded into the meta model (ST102). In one embodiment of the invention, “loading” the characteristics model into the meta model includes extracting specific pieces of information about the characteristics model (such as the information described in the meta model schema shown in FIG. 2) and loading the extracted information into the meta model.
Continuing with the discussion of FIG. 4, a schema for the characteristics store is subsequently created and associated with characteristics model (ST104). One or more characteristics extractors associated with characteristics model are subsequently created (ST106). Finally, a characteristics store API is created (ST108). In one embodiment of the invention, creating the characteristics store API includes creating a mapping between characteristics obtained by the characteristics extractors and tables defined by the schema configured to store the characteristics in the characteristics store.
Those skilled in the art will appreciate that ST100-ST108 may be repeated for each characteristics model. In addition, those skilled in the art will appreciate that once a characteristics store API is created, the characteristics store API may only need to be modified to support additional schemas in the characteristics data store and additional characteristics extractors. Alternatively, each characteristics model may be associated with a different characteristics store API.
At this stage, the system is ready to analyze a target system. FIG. 5 shows a flowchart in accordance with one embodiment of the invention. Initially, characteristics are obtained from the target system using one or more characteristics extractors (ST110). In one embodiment of the invention, the characteristics extractors associated with a given characteristics model only obtain information about characteristics associated with the artifacts defined in the characteristics model.
Continuing with the discussion of FIG. 5, the characteristics obtained from the target system using the characteristics extractors are stored in the characteristics store using the characteristics store API (ST112). Once the characteristics are stored in the characteristics store, the target system may be analyzed using the characteristics model (or models), the query engine, the meta model, and the characteristics stored in the characteristics store (ST114) (describe below in FIG. 6). In one embodiment of the invention, the user uses the query engine to issue queries to characteristics store. As discussed above, the query engine has access, via the meta model, to information about the characteristics models currently being used to analyze the target system. The results of the analysis are subsequently displayed using a visualization engine (ST116).
FIG. 6 shows a flowchart in accordance with one embodiment of the invention. Initially, a PQL query is received by the query engine (ST120). The PQL query is subsequently verified using the meta model (ST122). In one embodiment of the invention, verifying the PQL query includes searching the meta model to determine whether each component in the PQL query (i.e., artifact, characteristic, or relationship) is present in the meta model. If the meta model is implemented as a series of tables in accordance with a meta model schema (such as the one shown in FIG. 2), then searching the meta model includes searching the various tables in the meta model.
A determination of whether the verification of the PQL query was successful is subsequently made (ST124). The verification of the PQL query is successful if every component in the PQL query is present in the meta model.
The following is an example of PQL query and the process involved in verifying the various components of the PQL query.
Query
SELECT c from JClass c WHERE c.parentPackage.name=“java.lang”
When the above query is submitted to the meta model for verification, the meta model first determines whether the “JClass” component is present in the meta model. Assuming that the Java™ characteristics model (described above) is loaded into the meta model, then the meta model will discover that “JClass” is an artifact. Next, the meta model will attempt to verify whether “c.parentPackage.name” is a valid component. Since “c” is selected from “JClass” (as defined in the query), the component “c.parentPackage.name” may be re-written as “JClass.parentPackage.name.” As defined in the Java™ characteristics model discussed above, “JClass” is related to “JPackage” through a “parentPackage” relationship. Further, “name” is a characteristic of “JPackage,” thus the component “JClass.parentPackage.name” is a valid component. As there are no other components in the query to verify, the verification of the query is complete and successful.
Continuing with the discussion of FIG. 6, if the verification is not successful, then the query engine may request a new or modified PQL query (ST126). If a new or modified PQL query is submitted, then the method proceeds to ST120. Alternatively, if a new or modified PQL query is not submitted, then the method ends. Those skilled in the art will appreciate that the meta model may also issue an error message indicating that the verification was not successful.
If the PQL query is successfully verified, then PQL query is translated into a query understood by the characteristics store using the schema(s) associated with the various components in the PQL query (ST128). As discussed above, the characteristics store may not include functionality to query the characteristics using a PQL query. In such cases, the PQL query is translated into a query understood by the characteristics store, for example, an SQL query. In one embodiment of the invention, translating the PQL query into, for example, an SQL query includes obtaining information about how specific components (i.e., artifacts, characteristics, and relationships) are referred to in the characteristics store. Thus, the meta model, upon successful verification of the PQL query, may query the individual characteristics models to determine how each of the components in the PQL query are represented in the characteristics store (i.e., what table each component is in, what name is used to refer to the component in the characteristics store, etc.).
Continuing with the discussion of FIG. 6, the query resulting from the translation is subsequently issued to the characteristics store (ST130), and the results of the query are then returned to the query engine (ST132). Those skilled in the art will appreciate that while FIG. 6 refers to PQL and SQL queries, other query languages (such as those discussed above) may be used. Further, those skilled in the art will appreciate that STI10-ST112 may be performed concurrently with ST114-ST116. In addition, steps in FIG. 4, FIG. 5, and FIG. 6 may be performed concurrently.
An embodiment of the invention may be implemented on virtually any type of computer regardless of the platform being used. For example, as shown in FIG. 7, a networked computer system (200) includes a processor (202), associated memory (204), a storage device (206), and numerous other elements and functionalities typical of today's computers (not shown). The networked computer (200) may also include input means, such as a keyboard (208) and a mouse (210), and output means, such as a monitor (212). The networked computer system (200) is connected to a local area network (LAN) or a wide area network via a network interface connection (not shown). Those skilled in the art will appreciate that these input and output means may take other forms. Further, those skilled in the art will appreciate that one or more elements of the aforementioned computer (200) may be located at a remote location and connected to the other elements over a network. Further, software instructions to perform embodiments of the invention may be stored on a computer readable medium such as a compact disc (CD), a diskette, a tape, or any other physical computer readable storage device.
While the invention has been described with respect to a limited number of embodiments, those skilled in the art, having benefit of this disclosure, will appreciate that other embodiments can be devised which do not depart from the scope of the invention as disclosed herein. Accordingly, the scope of the invention should be limited only by the attached claims.

Claims (16)

1. A method for analyzing a target system, comprising:
obtaining a characteristics model, wherein the characteristics model comprises a plurality of artifacts, at least one relationship between a first one of the plurality of artifacts and a second one of the plurality of artifacts, and at least one characteristic associated with each of the plurality of artifacts, wherein the characteristics model is stored on a physical computer readable medium;
loading the characteristics model into a meta model, wherein the meta model comprises information describing attributes, characteristics, and relationships of the characteristics model;
obtaining a plurality of characteristics from the target system using a characteristics extractor, wherein each of the plurality of characteristics is associated with the characteristics model, wherein the target system comprises a combination of hardware and software;
storing each of the plurality of characteristics obtained from the target system in a characteristics store;
receiving, by a query engine executing on a processor, at least one query;
verifying the at least one query by traversing the meta model to determine whether each component within the at least one query is defined in the meta model; and
analyzing, in response to the verifying, the target system by issuing the at least one query to the characteristics store to obtain an analysis result, generating the characteristics extractor associated with the characteristics model; and
generating a characteristics store application programming interface (API) associated with the characteristics model, wherein the characteristics extractor uses the characteristics store API to store each of the plurality of characteristics in the characteristics store.
2. The method of claim 1, wherein the meta model is associated with a meta model schema, wherein the meta model schema comprises a plurality of meta attributes, a plurality of meta characteristics, and a plurality of meta relationships, wherein each of the plurality of meta attributes is configured to store a name of one of the plurality of artifacts, wherein each of the plurality of the meta relationships is configured to store a name for the at least one relationship, wherein each of the plurality of meta characteristics is configured to store a name for the at least one characteristics associated with each of the plurality of artifacts.
3. The method of claim 1, wherein each component within the at least one query comprises one selected from the group consisting of a characteristic, an artifact, and a relationship.
4. The method of claim 1, further comprising translating the at least one query from a pattern query language query into a query language supported by the characteristics store, when the at least one query is successfully verified.
5. The method of claim 4, wherein translating the at least one query comprises using a schema implemented in the characteristics store, wherein the schema is associated with the characteristics model.
6. The method of claim 1, wherein the at least one query is defined using a pattern query language.
7. The method of claim 6, wherein the pattern query language includes functionality to search for at least one software pattern in the target system.
8. A system for analyzing a target system, comprising:
a processor;
a memory;
a meta model comprising information about attributes, characteristics, and relationships of a characteristics model, wherein the characteristics model comprises a plurality of artifacts, at least one relationship between a first one of the plurality of artifacts and a second one of the plurality of artifacts, and at least one characteristic associated with each of the plurality of artifacts, wherein the characteristics model is stored on the memory;
the target system comprising a plurality of characteristics, wherein the target system comprises a combination of hardware and software;
at least one characteristics extractor configured to obtain at least one of the plurality of characteristics from the target system, wherein the at least one of the plurality of characteristics is defined in the characteristics model;
a characteristics store configured to store the at least one of the plurality of characteristics obtained from the target system; and
a query engine, executing on the processor, configured to:
verify at least one query by traversing the meta model to determine whether each component within the at least one query is defined in the meta model; and
analyze, in response to the verifying, the target system by issuing the at least one query to the characteristics store; and
obtain an analysis result in response to the at least one query generating the characteristics extractor associated with the characteristics model; and
generating a characteristics store application programming interface (API) associated with the characteristics model, wherein the characteristics extractor uses the characteristics store API to store each of the plurality of characteristics in the characteristics store.
9. The system of claim 8, wherein the meta model is associated with a meta model schema, wherein the meta model schema comprises a plurality of meta attributes, a plurality of meta characteristics, and a plurality of meta relationships, wherein each of the plurality of meta attributes is configured to store a name of one the plurality of artifacts, wherein the meta relationship is configured to store a name for the at least one relationship, wherein each of the plurality of meta characteristics are configured to store a name for the at least one characteristics associated with each of the plurality of artifacts.
10. The system of claim 8, wherein extracting the contents of the characteristics model comprises obtaining information about the characteristics model to create a meta model instance of the characteristics model using a meta model schema associated with the meta model.
11. The system of claim 8, wherein each component within the at least one query comprises one selected from the group consisting of a characteristic, an artifact, and a relationship.
12. The system of claim 8, further comprising translating the at least one query from a pattern query language query into a query language supported by the characteristics store, if the at least one query is successfully verified.
13. The system of claim 12, wherein translating the at least one query comprises using a schema implemented in the characteristics store, wherein the schema is associated with the characteristics model.
14. The system of claim 8, wherein the at least one query is defined using a pattern query language and wherein the pattern query language includes functionality to search for at least one pattern in the target system.
15. A computer readable storage medium comprising software instructions for analyzing a target system, the software instructions executable on a computer to:
obtain a characteristics model, wherein the characteristics model comprises a plurality of artifacts, at least one relationship between a first one of the plurality of artifacts and a second one of the plurality of artifacts, and at least one characteristic associated with each of the plurality of artifacts, wherein the characteristics model is stored on a physical computer readable medium;
load the characteristics model into a meta model, wherein the meta model comprises functionality to store information describing attributes, characteristics, and relationships of the characteristics model;
obtain a plurality of characteristics from the target system using a characteristics extractor, wherein each of the plurality of characteristics is associated with the characteristics model, wherein the target system comprises a combination of hardware and software;
store each of the plurality of characteristics obtained from the target system in a characteristics store;
receive, by a query engine executing on a processor, at least one query;
verify the at least one query by traversing the meta model to determine whether each component within the at least one query is defined in the meta model; and
analyze, in response to the verifying, the target system by issuing the at least one query to the characteristics store to obtain an analysis result.
16. The computer readable storage medium of claim 15, wherein each component comprises one selected from the group consisting of a characteristic, an artifact, and a relationship.
US11/134,021 2005-05-20 2005-05-20 Method and apparatus for pattern-based system design analysis using a meta model Active 2028-07-30 US7634766B2 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US11/134,021 US7634766B2 (en) 2005-05-20 2005-05-20 Method and apparatus for pattern-based system design analysis using a meta model
PCT/US2005/018003 WO2006126989A1 (en) 2005-05-20 2005-05-23 Method and apparatus for pattern-based system design analysis

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US11/134,021 US7634766B2 (en) 2005-05-20 2005-05-20 Method and apparatus for pattern-based system design analysis using a meta model

Publications (2)

Publication Number Publication Date
US20060265699A1 US20060265699A1 (en) 2006-11-23
US7634766B2 true US7634766B2 (en) 2009-12-15

Family

ID=37449712

Family Applications (1)

Application Number Title Priority Date Filing Date
US11/134,021 Active 2028-07-30 US7634766B2 (en) 2005-05-20 2005-05-20 Method and apparatus for pattern-based system design analysis using a meta model

Country Status (1)

Country Link
US (1) US7634766B2 (en)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080177622A1 (en) * 2005-10-11 2008-07-24 Akkiraju Ramakalyani T System and method for conducting dependency analysis of business components
US20080201611A1 (en) * 2007-02-16 2008-08-21 Kathryn Allyn Bassin Defect Resolution Methodology Target Assessment Process
US20100333073A1 (en) * 2009-06-29 2010-12-30 Honeywell International Inc. Systems and methods for automated generation of software tests based on modeling the software test domain
US20110161941A1 (en) * 2009-12-29 2011-06-30 Microgen Plc Creation of form-based applications
US8655901B1 (en) * 2010-06-23 2014-02-18 Google Inc. Translation-based query pattern mining

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8468512B2 (en) * 2009-10-30 2013-06-18 International Business Machines Corporation Abstracting benefit rules from computer code
US9128724B2 (en) * 2012-08-28 2015-09-08 International Business Machines Corporation Configuring assembly of a system using supplied architectural artifacts
US9645807B2 (en) 2012-08-28 2017-05-09 International Business Machines Corporation Automated deployment of a configured system into a computing environment
US10324908B2 (en) * 2016-09-01 2019-06-18 Sap Se Exposing database artifacts
US11048815B2 (en) 2018-08-06 2021-06-29 Snowflake Inc. Secure data sharing in a multi-tenant database system
CN109933307A (en) * 2019-02-18 2019-06-25 杭州电子科技大学 A kind of intelligent controller machine learning algorithm modular form description and packaging method based on ontology
WO2022250564A1 (en) * 2021-05-27 2022-12-01 Публичное Акционерное Общество "Сбербанк России" Method and system for verifying the architecture of a software/hardware solution

Citations (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5649200A (en) * 1993-01-08 1997-07-15 Atria Software, Inc. Dynamic rule-based version control system
US5664173A (en) * 1995-11-27 1997-09-02 Microsoft Corporation Method and apparatus for generating database queries from a meta-query pattern
US5752245A (en) * 1994-12-09 1998-05-12 Object Technology Licensing Corporation Object-oriented system for configuration history management with a project workspace and project history database for draft identification
US5812840A (en) 1994-03-24 1998-09-22 Speedware Ltee./Ltd. Database query system
US5875334A (en) * 1995-10-27 1999-02-23 International Business Machines Corporation System, method, and program for extending a SQL compiler for handling control statements packaged with SQL query statements
US5911139A (en) * 1996-03-29 1999-06-08 Virage, Inc. Visual image database search engine which allows for different schema
US6023694A (en) * 1996-01-02 2000-02-08 Timeline, Inc. Data retrieval method and apparatus with multiple source capability
US6199195B1 (en) * 1999-07-08 2001-03-06 Science Application International Corporation Automatically generated objects within extensible object frameworks and links to enterprise resources
US20010042067A1 (en) 1999-10-04 2001-11-15 Homayoun Dayani-Fard Dynamic semi-structured repository for mining software and software-related information
US6366922B1 (en) * 1998-09-30 2002-04-02 I2 Technologies Us, Inc. Multi-dimensional data management system
US6430553B1 (en) * 2000-03-22 2002-08-06 Exactone.Com, Inc. Method and apparatus for parsing data
US6446256B1 (en) * 1999-06-30 2002-09-03 Microsoft Corporation Extension of parsable structures
GB2383152A (en) 2001-12-17 2003-06-18 Oracle Corp Storing object versions in a database with delta files
US20030200280A1 (en) 1997-11-14 2003-10-23 National Instruments Corporation Assembly of a graphical program for accessing data from a data source/target
US20040059812A1 (en) 2000-12-14 2004-03-25 Shmuel Assa Topology information system for a managed world
US20040093344A1 (en) 2001-05-25 2004-05-13 Ben Berger Method and system for mapping enterprise data assets to a semantic information model
US6760903B1 (en) 1996-08-27 2004-07-06 Compuware Corporation Coordinated application monitoring in a distributed computing environment
US20040255291A1 (en) 2003-01-17 2004-12-16 Sierer Brian H. Installing software using programmatic component dependency analysis
US20050044197A1 (en) 2003-08-18 2005-02-24 Sun Microsystems.Inc. Structured methodology and design patterns for web services
US20050044060A1 (en) 2003-08-18 2005-02-24 Yuh-Cherng Wu Filtering process for information retrieval systems
US20050198616A1 (en) 2004-03-08 2005-09-08 Fujitsu Limited Pattern system generation apparatus and pattern application apparatus
US20060124738A1 (en) 2004-12-14 2006-06-15 Fusheng Wang Systems, devices, and methods for managing RFID data
US7100152B1 (en) * 2000-01-31 2006-08-29 Freescale Semiconductor, Inc. Software analysis system having an apparatus for selectively collecting analysis data from a target system executing software instrumented with tag statements and method for use thereof
US7137100B2 (en) * 2000-04-04 2006-11-14 Jose Iborra Automatic software production system
US7140000B2 (en) * 2001-10-09 2006-11-21 Certusoft Knowledge oriented programming
US20060265698A1 (en) 2005-05-20 2006-11-23 Sun Microsystems, Inc. Method and apparatus for tracking changes in a system
US7243337B1 (en) 2000-04-12 2007-07-10 Compuware Corporation Managing hardware and software configuration information of systems being tested
US7248971B1 (en) 2000-11-14 2007-07-24 International Business Machines Corporation Method and apparatus for discovering patterns in a set of sequences
US7289997B1 (en) * 2004-04-23 2007-10-30 Sun Microsystems, Inc. System and method for an extensible metadata driven application framework
US7337170B2 (en) * 2005-01-18 2008-02-26 International Business Machines Corporation System and method for planning and generating queries for multi-dimensional analysis using domain models and data federation
US7475080B2 (en) * 2004-11-23 2009-01-06 International Business Machines Corporation Adaptive data warehouse meta model method
US7530050B2 (en) * 2000-03-14 2009-05-05 Fusionops Method and system for developing software using nodes
US7533365B1 (en) * 2004-02-03 2009-05-12 Borland Software Corporation Development system with methodology for run-time restoration of UML model from program code
US7571434B1 (en) * 2005-05-20 2009-08-04 Sun Microsystems, Inc. Method and apparatus for transparent invocation of a characteristics extractor for pattern-based system design analysis

Patent Citations (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5649200A (en) * 1993-01-08 1997-07-15 Atria Software, Inc. Dynamic rule-based version control system
US5812840A (en) 1994-03-24 1998-09-22 Speedware Ltee./Ltd. Database query system
US5752245A (en) * 1994-12-09 1998-05-12 Object Technology Licensing Corporation Object-oriented system for configuration history management with a project workspace and project history database for draft identification
US5875334A (en) * 1995-10-27 1999-02-23 International Business Machines Corporation System, method, and program for extending a SQL compiler for handling control statements packaged with SQL query statements
US5664173A (en) * 1995-11-27 1997-09-02 Microsoft Corporation Method and apparatus for generating database queries from a meta-query pattern
US6023694A (en) * 1996-01-02 2000-02-08 Timeline, Inc. Data retrieval method and apparatus with multiple source capability
US5911139A (en) * 1996-03-29 1999-06-08 Virage, Inc. Visual image database search engine which allows for different schema
US6760903B1 (en) 1996-08-27 2004-07-06 Compuware Corporation Coordinated application monitoring in a distributed computing environment
US20030200280A1 (en) 1997-11-14 2003-10-23 National Instruments Corporation Assembly of a graphical program for accessing data from a data source/target
US6366922B1 (en) * 1998-09-30 2002-04-02 I2 Technologies Us, Inc. Multi-dimensional data management system
US6446256B1 (en) * 1999-06-30 2002-09-03 Microsoft Corporation Extension of parsable structures
US6199195B1 (en) * 1999-07-08 2001-03-06 Science Application International Corporation Automatically generated objects within extensible object frameworks and links to enterprise resources
US20010042067A1 (en) 1999-10-04 2001-11-15 Homayoun Dayani-Fard Dynamic semi-structured repository for mining software and software-related information
US7100152B1 (en) * 2000-01-31 2006-08-29 Freescale Semiconductor, Inc. Software analysis system having an apparatus for selectively collecting analysis data from a target system executing software instrumented with tag statements and method for use thereof
US7530050B2 (en) * 2000-03-14 2009-05-05 Fusionops Method and system for developing software using nodes
US6430553B1 (en) * 2000-03-22 2002-08-06 Exactone.Com, Inc. Method and apparatus for parsing data
US7137100B2 (en) * 2000-04-04 2006-11-14 Jose Iborra Automatic software production system
US7243337B1 (en) 2000-04-12 2007-07-10 Compuware Corporation Managing hardware and software configuration information of systems being tested
US7248971B1 (en) 2000-11-14 2007-07-24 International Business Machines Corporation Method and apparatus for discovering patterns in a set of sequences
US20040059812A1 (en) 2000-12-14 2004-03-25 Shmuel Assa Topology information system for a managed world
US20040093344A1 (en) 2001-05-25 2004-05-13 Ben Berger Method and system for mapping enterprise data assets to a semantic information model
US7140000B2 (en) * 2001-10-09 2006-11-21 Certusoft Knowledge oriented programming
GB2383152A (en) 2001-12-17 2003-06-18 Oracle Corp Storing object versions in a database with delta files
US20040255291A1 (en) 2003-01-17 2004-12-16 Sierer Brian H. Installing software using programmatic component dependency analysis
US20050044197A1 (en) 2003-08-18 2005-02-24 Sun Microsystems.Inc. Structured methodology and design patterns for web services
US20050044060A1 (en) 2003-08-18 2005-02-24 Yuh-Cherng Wu Filtering process for information retrieval systems
US7533365B1 (en) * 2004-02-03 2009-05-12 Borland Software Corporation Development system with methodology for run-time restoration of UML model from program code
US20050198616A1 (en) 2004-03-08 2005-09-08 Fujitsu Limited Pattern system generation apparatus and pattern application apparatus
US7289997B1 (en) * 2004-04-23 2007-10-30 Sun Microsystems, Inc. System and method for an extensible metadata driven application framework
US7475080B2 (en) * 2004-11-23 2009-01-06 International Business Machines Corporation Adaptive data warehouse meta model method
US20060124738A1 (en) 2004-12-14 2006-06-15 Fusheng Wang Systems, devices, and methods for managing RFID data
US7337170B2 (en) * 2005-01-18 2008-02-26 International Business Machines Corporation System and method for planning and generating queries for multi-dimensional analysis using domain models and data federation
US20060265698A1 (en) 2005-05-20 2006-11-23 Sun Microsystems, Inc. Method and apparatus for tracking changes in a system
US7571434B1 (en) * 2005-05-20 2009-08-04 Sun Microsystems, Inc. Method and apparatus for transparent invocation of a characteristics extractor for pattern-based system design analysis

Non-Patent Citations (35)

* Cited by examiner, † Cited by third party
Title
"CAST Application Intelligence Platform Empowering Application Management"; CAST The Application Intelligence Company; Oct. 2004 (2 pages).
"Fixing Software on the Assembly Line" An Overview of Coverity's Static Code Analysis Technology; (26 pages).
"Hammurapi Group"; pp. 1-7.
"J2EE Code Validation Preview for WebSphere Studio"; (2 pages).
"J2EE Code Validation Preview for WebSphere Studio"; Mar. 21, 2005 (3 pages).
"SQL Compiler (for Java) Free your Java code from SQL statements-compile them to Java classes"; May 1, 2005 (9 pages).
"SQL Compiler (for Java)"; (8 pages).
"Structural Analysis of Java"; Mar. 1, 2004 (2 pages).
Agitar Data Sheet; "Agitator & Management Dashboard"; Agitar Software 2003-2005; (4 pages).
Aldrich, et al; "Architectural Reasoning in ArchJava"; Department of Computer Science and Engineering; University of Washington; 2002; pp. 1-34.
Atkins, David L.; "Version Sensitive Editing: Change History as a Programming Tool"; System Configuration Management; ECOOP '98, SCM-8 Symposium, Proceedings 1998, Berlin, Germany; pp. 146-157, 1998 (12 pages).
Bessam et al, "Software architecture between meta mode for real time systems", IEEE, pp. 245-252, 2008. *
Carriere et al.; "Assessing Design Quality From a Software Architectural Perspective"; OOPSLA '97 Workshop on Object-Oriented Design Quality; Oct. 5, 1997 (4 pages).
Ellsworth et al; "JUnit+Jtest=Automated Test Case Design and Static Analysis"; (3 pages).
Ellsworth et al; "JUnit+Jtest=Automated Test Case Design and Static Analysis"; May 9, 2003 (3 pages).
Hallem, et al.; "Uprooting Software Defects at the Source"; Instant Messaging, vol. 1, No. 8, Nov. 2003; pp. 1-9.
Hassan et al.; "Architecture Recovery of Web Applications"; The Guide to Computing Literature; International Conference on Software Engineering; 2002; (12 pages).
Huang et al, "Adaptively constructing the query interface for meta search engines", ACM IUI, pp. 92-100, 2001. *
International Preliminary Report dated Dec. 6, 2007 (7 pages).
International Preliminary Report dated Dec. 6, 2007 (8 pages).
International Search Report dated Feb. 15, 2006 (3 pages).
Jarzabek, S.; "Design of Flexible Static Program Analyzers with PQL"; IEEE Transactions on Software Engineering, IEEE Service Center, vol. 24, No. 3, Mar. 1, 1998; pp. 197-215 (19 pages).
Kamran Sartipi; "Software Architecture Recovery Based on Pattern Matching"; School of Computer Science, University of Waterloo; Proceedings of the International Conference on Software Maintenance (ICSM'03); IEEE Computer Society (4 pages).
Lange, C. et al.; "Comparing Graph-based Program Comprehension Tools to Relational Database-based Tools"; Program Comprehension, 2001; IWPC 2001 Proceedings; 9th International Workshop on May 12-13, 2001, Piscataway, NJ; IEEE 2001; pp. 209-218 (10 pages).
Lovatt, et al.; "A Pattern Enforcing Compiler (PEC) for Java: Using the Compiler"; Department of Computing, Macquarie University; 2005 Australian Computer Society, Inc.; (10 pages).
Masiero, P. et al.; "Legacy Systems Reengineering Using Software Patterns"; Computer Science Society, 1999, Proceedings SCCC '99; XIX International Conference of the Chilean Talca, Chile, Nov. 11-13, 1999; IEEE Computer Science; pp. 160-169 (10 pages).
Moon et al, "Managing and querying transaction time databses under scheme evolution", ACM PVLDB, pp. 882-895, 2008. *
Paul, S. et al.; "Source Code Retrieval Using Program Patterns"; Computer-Aided Software Engineering, 1992, Proceedings, Fifth International Workshop, Montreal, Quebec, Canada, Jul. 6-10, 1992; IEEE Computer Science, Jul. 6, 1992; pp. 92-105 (11 pages).
PCT International Search Report dated Jan. 23, 2006 for PCT/US/2005/018003 (4 pages).
PCT International Search Report dated Jan. 4, 2006 for PCT/US2005/018004 (4 pages).
PCT International Search Report dated Jan. 4, 2006 for PCT/US2005/018008 (4 pages).
Prof. Victor V. Martynov, EHU; "SEMPL Semantic Patterns Language"; Summary Chapter from the book "Foundations of Samantic Coding", pp. 128-138, EHU, 2001 (9 pages).
Sartipi, K. et al.; "A Graph Pattern Matching Approach to Software Architecture Recovery"; Proceedings IEEE International Conference on Software Maintenance; ICSM-2001, Florence, Italy, Nov. 7-9, 2001; pp. 408-419 (12 pages).
Sartipi, K. et al.; "A Pattern Matching Framework for Software Architecture Recovery and Restructuring"; Proceedings IWPC'00; 8th International Workshop on Program Comprehension, Jun. 10, 2000, pp. 1-11 (11 pages).
Srivastava et al, "Intensional associations between data and metadata", ACM SIGMOD, pp. 401-412, 2007. *

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080177622A1 (en) * 2005-10-11 2008-07-24 Akkiraju Ramakalyani T System and method for conducting dependency analysis of business components
US8341592B2 (en) * 2005-10-11 2012-12-25 International Business Machines Corporation System and method for conducting dependency analysis of business components
US20080201611A1 (en) * 2007-02-16 2008-08-21 Kathryn Allyn Bassin Defect Resolution Methodology Target Assessment Process
US7917897B2 (en) * 2007-02-16 2011-03-29 International Business Machines Corporation Defect resolution methodology and target assessment process with a software system
US20100333073A1 (en) * 2009-06-29 2010-12-30 Honeywell International Inc. Systems and methods for automated generation of software tests based on modeling the software test domain
US20110161941A1 (en) * 2009-12-29 2011-06-30 Microgen Plc Creation of form-based applications
US8464229B2 (en) * 2009-12-29 2013-06-11 Microgen Aptitude Limited Creation of form-based software application in a graphical user interface (GUI) environment
US8655901B1 (en) * 2010-06-23 2014-02-18 Google Inc. Translation-based query pattern mining

Also Published As

Publication number Publication date
US20060265699A1 (en) 2006-11-23

Similar Documents

Publication Publication Date Title
US7634766B2 (en) Method and apparatus for pattern-based system design analysis using a meta model
US7653898B1 (en) Method and apparatus for generating a characteristics model for a pattern-based system design analysis using a schema
US8065323B2 (en) Offline validation of data in a database system for foreign key constraints
US7571434B1 (en) Method and apparatus for transparent invocation of a characteristics extractor for pattern-based system design analysis
US7814459B2 (en) System and method for automated on demand replication setup
US7970732B2 (en) Data migration
US8577927B2 (en) Producing a virtual database from data sources exhibiting heterogeneous schemas
US7870163B2 (en) Implementation of backward compatible XML schema evolution in a relational database system
US7194475B2 (en) Method, system, and program for performing an impact analysis of program statements in at least one source code file
Hartig SPARQL for a Web of Linked Data: Semantics and computability
US20180039490A1 (en) Systems and methods for transformation of reporting schema
US20060179116A1 (en) Configuration management system and method of discovering configuration data
US20060143144A1 (en) Rule sets for a configuration management system
US20060037000A1 (en) Configuration management data model using blueprints
US7096421B2 (en) System and method for comparing hashed XML files
US7490098B2 (en) Apparatus, system, and method for processing hierarchical data in disparate data repositories
US20040205509A1 (en) System and method for comparing parsed XML files
US7703074B2 (en) Method and apparatus for tracking changes in a system
US9870241B2 (en) Data transfer guide
US7203671B1 (en) System and method for validating the technical correctness of an OLAP reporting project
US20200089792A1 (en) Consistency checks between database systems
US7840603B2 (en) Method and apparatus for database change management
US20060265697A1 (en) Pattern query language
US20080209398A1 (en) Methods and Apparatus for Authentication of Configuration Items Via Configuration Item Change Analysis
CN112650526A (en) Version consistency detection method and device, electronic equipment and medium

Legal Events

Date Code Title Description
AS Assignment

Owner name: SUN MICROSYSTEMS, INC., CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:ALI, SYED M.;KAMEN, YURY;ALUR, DEEPAK;AND OTHERS;REEL/FRAME:016559/0980;SIGNING DATES FROM 20050514 TO 20050720

STCF Information on status: patent grant

Free format text: PATENTED CASE

CC Certificate of correction
CC Certificate of correction
FPAY Fee payment

Year of fee payment: 4

AS Assignment

Owner name: ORACLE AMERICA, INC., CALIFORNIA

Free format text: MERGER AND CHANGE OF NAME;ASSIGNORS:ORACLE USA, INC.;SUN MICROSYSTEMS, INC.;ORACLE AMERICA, INC.;REEL/FRAME:037305/0133

Effective date: 20100212

FPAY Fee payment

Year of fee payment: 8

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 12TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1553); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 12