[go: up one dir, main page]

WO2006126989A1 - Procede et appareil pour l'analyse de systeme sur la base de modeles - Google Patents

Procede et appareil pour l'analyse de systeme sur la base de modeles Download PDF

Info

Publication number
WO2006126989A1
WO2006126989A1 PCT/US2005/018003 US2005018003W WO2006126989A1 WO 2006126989 A1 WO2006126989 A1 WO 2006126989A1 US 2005018003 W US2005018003 W US 2005018003W WO 2006126989 A1 WO2006126989 A1 WO 2006126989A1
Authority
WO
WIPO (PCT)
Prior art keywords
query
model
meta
store
artifacts
Prior art date
Application number
PCT/US2005/018003
Other languages
English (en)
Inventor
Syed M. Ali
Yury Kamen
Deepak Alur
John P. Crupi
Daniel B. Malks
Rajmohan Krishnamurthy
Michael W. Godfrey
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
Priority claimed from US11/134,062 external-priority patent/US20060265700A1/en
Priority claimed from US11/134,021 external-priority patent/US7634766B2/en
Application filed by Sun Microsystems, Inc., filed Critical Sun Microsystems, Inc.,
Publication of WO2006126989A1 publication Critical patent/WO2006126989A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/75—Structural analysis for program understanding

Definitions

  • 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.
  • 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 in general, in one aspect, 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. 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 (102A), characteristics extractor N (102N)), a characteristics store application programming interface (API) (104), a characteristics store (106), one or more characteristics models (108 A, 108N), a meta model (109), a query engine (110), and visualization engine (112).
  • characteristics extractors e.g., characteristics extractor A (102A), characteristics extractor N (102N)
  • API application programming interface
  • the domain corresponds to any grouping of "related artifacts" (i.e., there is a relationship between the artifacts).
  • domains include, but are not limited to, a JavaTM 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 JavaTM domain (described below).
  • J2EE JavaTM 2 Enterprise Edition
  • a networking domain that includes artifacts such as web server, domain name server, network interface cards, etc
  • DTrace domain that includes artifacts such as network, cpu, process, thread stack, function call, etc.
  • JavaTM domain described below.
  • each of the characteristics models (108 A, 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 (108 A, 108N) is shown in FIG. 3.
  • 108A, 108N enables a user to analyze the target system (100) with respect to a specific domain. Further, the use of multiple characteristics models (108 A, 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).
  • the meta model (109) provides a layer of abstraction between the other components in the system and the characteristics models (108 A, 108N).
  • 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.
  • the meta model (109) includes functionality to extract specific pieces of information from the characteristics models (108 A, 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.
  • the characteristics extractors are used to obtain information about various artifacts (i.e., characteristics) defined in the characteristics models (108A, 108N).
  • the characteristics models (108A, 108N) are used to generate the characteristics extractor (e.g., characteristics extractor A (102A), characteristics extractor N (102N)).
  • the characteristics extractors are generated using the characteristics models (108A, 108N).
  • 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 (102A), characteristics extractor N (102N)
  • 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 (102A), characteristics extractor N (102N)
  • 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 (108A, 108N).
  • each characteristics extractor typically only retrieves information about artifacts described in the characteristics model (108 A, 108N) with which the characteristics extractor is associated.
  • each characteristics model (108A, 108N) may be associated with one or more characteristics extractors.
  • 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.
  • 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).
  • SQL Structure Query Language
  • the characteristics model (108 A, 108N) may be used to generate a schema for storing the characteristics associated with the particular characteristics model (108A, 108N).
  • each characteristics model (108 A, 108N) within the system may be associated with a separate schema.
  • the characteristics store (104) is a relational database that includes a schema generated from the characteristics model (108 A, 108N)
  • 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 (108A, 108N).
  • 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 (108A, 108N) to the various tables within the schema is stored in the corresponding characteristics model (108 A, 108N).
  • 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. 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.
  • 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 (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).
  • 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 (108A, 108N).
  • 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 (108 A, 108N) corresponds to the representation of the particular characteristics model within the meta model (109).
  • the representation of a characteristics model (108A, 108N) in the meta model is dictated by the meta model schema.
  • 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).
  • 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 (108A, 108N).
  • 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 (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.
  • 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.
  • JavaTM Characteristics Model persistent class JFactDatabase ⁇ long id primary key; String version; String name; String sourceFile; references JPackage packages(0,n) inverse factDatabase(l,l); ⁇ // class JFactDatabase persistent class JPackage ⁇ long id primary key; String version; String name; String shortName; references JPackage packages (0,n) inverse parentPackage(l,l); references JClass classes (0,n) inverse parentPackage(l,l); ⁇ // class JPackage persistent class JClass ⁇ long id primary key; String version; String name; String shortName; Boolean isStatic; Boolean isFinal; Boolean islnner; String accessibility; String sourceFile; Integer filePosition; references JClass implementslnterfaces( ⁇ ,n) inverse implementingClasses(O,n); references JClass extendsClass(O,l) inverse extendingClasses(O,n); references JClass contains(0,
  • 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.
  • FIG. 3 shows each of the aforementioned JavaTM 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.
  • 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.
  • JavaTM Schema CREATE TABLE JFactDatabase( id INTEGER, version VARCHAR(255), name VARCHAR(255), sourceFile VARCHAR(255), PRIMARY KEY ( id ) ); CREATE UNIQUE INDEX JFactDatabase PRIMARY KEY ON JFactDatabase(id); CREATE UNIQUE INDEX JFactDatabase_name ON JFactDatabase(name); COMMIT; CREATE TABLE JPackage( id INTEGER, version VARCHAR(255), name VARCHAR(255), shortName VARCHAR(255), factDatabase INTEGER, PRIMARY KEY ( id ) ); CREATE UNIQUE INDEX JPackage_PRIMARY_KEY ON JPackage(id); CREATE UNIQUE INDEX JPackage_name ON JPackage(name);
  • 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 l :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 (STlOO).
  • 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. [0052] Continuing with the discussion of FIG.
  • a schema for the characteristics store is subsequently created and associated with characteristics model (STl 04).
  • 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.
  • STl 00-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. Initially, characteristics are obtained from the target system using one or more characteristics extractors (STI lO). 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.
  • STI lO characteristics extractors
  • the characteristics obtained from the target system using the characteristics extractors are stored in the characteristics store using the characteristics store API (STl 12).
  • 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 (STl 14) (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 (STl 16).
  • FIG. 6 shows a flowchart in accordance with one embodiment of the invention.
  • a PQL query is received by the query engine (ST120).
  • 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 (ST124).
  • 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 (ST128).
  • 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 (ST132).
  • ST 130 the characteristics store
  • ST132 the results of the query are then returned to the query engine (ST132).
  • FIG. 6 refers to PQL and SQL queries, other query languages (such as those discussed above) may be used.
  • STI lO-STl 12 may be performed concurrently with STl 14-ST116.
  • steps in FIG. 4, FIG. 5, and FIG. 6 may be performed concurrently.
  • a networked computer system 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, a file, or any other 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

L'invention concerne un procédé pour analyser un système cible, consistant à: obtenir une pluralité de caractéristiques à partir du système cible au moyen d'un extracteur de caractéristiques, chacune des caractéristiques étant associée à un modèle de caractéristiques; mémoriser chacune des caractéristiques obtenues à partir du système cible dans une mémoire de caractéristiques; et analyser le système cible par envoi d'au moins une demande à la mémoire de caractéristiques dans le but d'obtenir un résultat d'analyse.
PCT/US2005/018003 2005-05-20 2005-05-23 Procede et appareil pour l'analyse de systeme sur la base de modeles WO2006126989A1 (fr)

Applications Claiming Priority (4)

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

Publications (1)

Publication Number Publication Date
WO2006126989A1 true WO2006126989A1 (fr) 2006-11-30

Family

ID=37452306

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2005/018003 WO2006126989A1 (fr) 2005-05-20 2005-05-23 Procede et appareil pour l'analyse de systeme sur la base de modeles

Country Status (1)

Country Link
WO (1) WO2006126989A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2021124962A (ja) * 2020-02-05 2021-08-30 富士通株式会社 管理プログラム，管理装置および管理方法

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010042067A1 (en) * 1999-10-04 2001-11-15 Homayoun Dayani-Fard Dynamic semi-structured repository for mining software and software-related information

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010042067A1 (en) * 1999-10-04 2001-11-15 Homayoun Dayani-Fard Dynamic semi-structured repository for mining software and software-related information

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
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 12-13 MAY 2001, PISCATAWAY, NJ, USA,IEEE, 12 May 2001 (2001-05-12), pages 209 - 218, XP010541022, ISBN: 0-7695-1131-7 *
SARTIPI K ET AL: "A pattern matching framework for software architecture recovery and restructuring", PROCEEDINGS IWPC'00. 8TH INTERNATIONAL WORKSHOP ON PROGRAM COMPREHENSION, 10 June 2000 (2000-06-10) - 11 June 2000 (2000-06-11), LIMERICK, IRELAND, pages 1 - 11, XP002357227, ISBN: 0-7695-0656-9 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2021124962A (ja) * 2020-02-05 2021-08-30 富士通株式会社 管理プログラム，管理装置および管理方法

Similar Documents

Publication Publication Date Title
US7814459B2 (en) System and method for automated on demand replication setup
US8065323B2 (en) Offline validation of data in a database system for foreign key constraints
CN102687124B (zh) 分析查询优化器性能的设备和方法
US7870163B2 (en) Implementation of backward compatible XML schema evolution in a relational database system
US8577927B2 (en) Producing a virtual database from data sources exhibiting heterogeneous schemas
US7970732B2 (en) Data migration
US7194475B2 (en) Method, system, and program for performing an impact analysis of program statements in at least one source code file
US8180810B2 (en) Interactive generation of integrated schemas
US20060143144A1 (en) Rule sets for a configuration management system
US20120272329A1 (en) Obfuscating sensitive data while preserving data usability
US20060037000A1 (en) Configuration management data model using blueprints
US8260813B2 (en) Flexible data archival using a model-driven approach
US20060149408A1 (en) Agent-less discovery of software components
US20040205509A1 (en) System and method for comparing parsed XML files
US20030177442A1 (en) System and method for comparing hashed XML files
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
Bisbal et al. A survey of research into legacy system migration
US7490098B2 (en) Apparatus, system, and method for processing hierarchical data in disparate data repositories
US7571434B1 (en) Method and apparatus for transparent invocation of a characteristics extractor for pattern-based system design analysis
US7703074B2 (en) Method and apparatus for tracking changes in a system
US20070112886A1 (en) Method and apparatus for database change management
WO2005055561A2 (fr) Systeme et procede de gestion de la configuration de composants de systemes de support d'operations
US20060265697A1 (en) Pattern query language
US20050114642A1 (en) System and method for managing OSS component configuration

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

NENP Non-entry into the national phase

Ref country code: RU

122 Ep: pct application non-entry in european phase

Ref document number: 05754442

Country of ref document: EP

Kind code of ref document: A1