JP2006338303A - Notation converting device, consistency checking device, and program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To support the recycling of software resources by performing at least either automatic conversion from a function hierarchy diagram extractable by a domain analysis into notation data by a UML (unified modeling language) or automatic conversion opposite to the above mentioned automatic conversion. <P>SOLUTION: A characteristic tree table 26 stores data of the function hierarchy diagram (characteristic tree diagram) extractable by domain analysis. A UML converting part 21 generates a UML description table 27 with notation data stored in a UML refering to the table 26. A characteristic tree converting part 24 generates a corresponding characteristic tree table 26 refering to the UML description table 27. A UML description table consistency checking part 22 checks consistency in the data stored in the UML description table 27. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to a technique for reusing software resources for developing an application program.

  The development of application programs (hereinafter abbreviated as “applications”) is usually very expensive. For this reason, in order to reduce the cost required for development, existing software resources are reused for application development. As a technique for making the reuse easier, there is a technique using a framework (Patent Documents 1 to 3, Non-Patent Documents 1 and 2). The framework is a collection of objects that are the smallest software unit. The object is defined by a “class”.

  In technologies using frameworks, reusable software resources are classified into domains, frameworks, multiple classes that make up frameworks, classes that implement application-specific functions, and interfaces between frameworks and classes. Is done. A domain is a rough summary of software resources closely associated with a specific business.

  Software resource reuse can be broadly divided into framework reuse and reuse corresponding to a class (hereinafter also referred to as “component”). When reusing a framework, one or more classes constituting the framework are identified, and an interface of the identified class and a class corresponding to the identified class is developed.

  The reuse of parts is small in granularity, and it is necessary to select, evaluate, and pick up many parts in order to obtain the effect of reuse. As a result, it is difficult to reuse a wide range of parts. On the other hand, the reuse of the framework has a large granularity, and a great effect can be obtained. For this reason, it is desired to make it easier to select or develop an appropriate framework.

  There is a FODA (Feature-Oriented Domain Analysis) method described in Non-Patent Document 1 as one that makes it easier to develop such a framework. In the FODA system, classes constituting a domain are classified by functional analysis, and the reuse of classes is supported by the classified functional units. The result of domain analysis is usually expressed as a function hierarchy diagram (hereinafter also referred to as “function tree” or “characteristic tree”) indicating the hierarchical relationship between functions.

  As is well known, application development involves designing (modeling) an application to be developed. In object-oriented design, UML (Unified Modeling Language), which is a unified notation for design drawings, is often used.

  The UML can be applied to MDA (Model Driven Architecture). Moreover, since it is a unified notation, it is easy to transmit information to others. From these facts, it can be considered that automatic conversion of the functional hierarchy diagram obtained by domain analysis into UML notation helps to develop an application more easily. Since a functional hierarchy diagram is easy to analyze a domain, it is desirable that UML notation can be converted into a functional hierarchy diagram in order to provide an environment in which an application can be developed more easily.

  From what has been described above, it can be said that the automatic conversion between them will support the development of applications more easily regardless of the direction. Therefore, automatic conversion between data expressed by different notation methods related to application development is considered to have great significance. Non-Patent Document 2 describes a technique for deploying a functional hierarchy diagram created by the FODA method for development, but does not describe deployment to UML.

In the prior art described in Patent Document 3, UML notation is performed by a person according to the following procedure.
(1) Create a program (object group) with object-oriented design (2) Divide the objects that make up the program into the application layer and the platform layer (3) Further the hardware life of the objects that make up the platform layer (4) Describe the relationship between objects in UML notation (class diagram) FIG. 12 is a diagram for explaining the UML notation according to the prior art described in Patent Document 3. FIG. 12A is a layer configuration diagram obtained by dividing an object into layers according to human judgment. 1201 is an application layer, 1202 is a platform layer, and 1211-1213 are platform platforms 1202 3. Each of the sublayers is shown. FIG. 11B is a class diagram in UML notation showing the relationship between the objects extracted from the divided objects as shown in the layer configuration diagram.
JP 7-36684 A JP 2003-337697 A JP 2000-97102 A Kyo C.I. Kang et al. “Feature-Oriented Domain Analysis (FODA) Feasibility Study”, CMU / SEI-90-TR-021 Kyo C.I. Kang et al. , “FORM: A feature-Oriented reuse method with domain-specific reference architectures”, Annals of Software Engineering 5 (1998) 143-168

  The present invention is a technology for supporting the reuse of software resources by performing at least one of automatic conversion from a functional hierarchy diagram that can be extracted by domain analysis to data expressed in UML and vice versa. The purpose is to provide.

  The notation conversion apparatus according to the first to fourth aspects of the present invention is based on the premise that automatic conversion between data expressed by different notation methods related to the development of an application program is performed. It has.

  The notation conversion apparatus according to the first aspect includes a data acquisition unit that acquires, as data, hierarchical diagram data indicating a functional hierarchy diagram that can be extracted by domain analysis, and a UML that automatically converts the hierarchical diagram data acquired by the data acquisition unit. Conversion means for generating UML data represented by.

The notation conversion device according to the second aspect further includes check means for checking the consistency of the UML data in addition to the configuration according to the first aspect.
The notation conversion device according to the third aspect further includes other conversion means for automatically converting UML data to generate hierarchical diagram data in addition to the configuration in the first or second aspect.

Note that it is preferable that the checking means performs a consistency check in consideration of automatic conversion of UML data into hierarchical diagram data.
The notation conversion device according to the fourth aspect includes a data acquisition unit that acquires UML data expressed in UML as data, and a function hierarchy that can automatically extract the UML data acquired by the data acquisition unit and extract it by domain analysis Conversion means for generating hierarchical diagram data showing the figure.

  On the premise that the consistency check device of the present invention is mounted on any one of the first to fourth notation conversion devices, data acquisition means for acquiring UML data expressed in UML as data, and data Checking means for checking the consistency of the UML data acquired by the acquiring means.

  The programs of the first to third aspects of the present invention each have a function for realizing the means included in the notation conversion apparatus of the first aspect, the notation conversion apparatus of the fourth aspect, and the consistency check apparatus. It is installed.

  The present invention acquires hierarchical diagram data indicating a functional hierarchical diagram that can be extracted by domain analysis, and automatically converts the hierarchical diagram data to generate UML data represented in UML. Therefore, it is possible to provide continuity from domain analysis of software resource reusability to application design and development. As a result, application development is supported in such a way that existing data can be used more easily and effectively.

  The present invention acquires UML data expressed in UML, automatically converts the UML data, and generates hierarchical diagram data indicating a functional hierarchy diagram that can be extracted by domain analysis. This makes it easy to analyze the domain of the designed application. As a result, application development is supported.

  The present invention acquires UML data expressed in UML, and checks the consistency of the UML data. The check enables an application developer to easily determine whether or not the UML data subject to the check is appropriate. Therefore, application development is supported.

  When the above inventions are combined, application development can be further supported.

Embodiments of the present invention will be described below with reference to the drawings.
FIG. 1 is a diagram for explaining a conversion target in the present embodiment. FIG. 1A is a characteristic tree diagram (functional hierarchy diagram) obtained by, for example, domain analysis by the FODA method, and FIG. 1B is a class diagram by UML notation. In the present embodiment, both a characteristic tree diagram as shown in FIG. 1A and a UML notation such as a class diagram as shown in FIG. 1B are to be converted, and the characteristic tree diagram is UML notation and UML notation is Each can be automatically converted into a characteristic tree diagram. The class diagram shown in FIG. 1B is obtained by converting the characteristic tree diagram shown in FIG.

  Each range surrounded by a wavy line in FIG. 1A represents a group of reusable characteristics (functions). The grouped characteristics are assumed to be reused on a group basis. In FIG. 1 (a), a characteristic excluded from the grouping (hereinafter referred to as “excluded characteristic” for convenience) having a hierarchical relationship with the grouped characteristic as a higher level is marked with a circle. As shown.

  Each characteristic is uniquely replaced with a class as shown in FIG. The attribute of the characteristic is treated as a note combined with a note anchor to the class, thereby saving the attribute data used in the domain analysis. Between the characteristics constituting the group, a hierarchical relationship is expressed as a description of generalization of UML. The exclusion characteristic is expressed by the relationship between the upper class and the UML composition. Although not shown in FIG. 1 (a), the description of the generalization of UML for the composition relation class when the exclusion characteristic has a tree-like structure, that is, when there are a plurality of characteristics. As a hierarchical relationship.

  By automatically converting the characteristic tree diagram to UML notation, it becomes possible to export and import to the UML tool and MDA tool without troublesome work. By automatically converting the UML notation into a characteristic tree diagram, it becomes possible to support domain analysis. Therefore, application development is supported so that any conversion can be performed more easily. With this support, quality improvement, short delivery time, or cost reduction in application development can be realized more easily.

FIG. 2 is a diagram for explaining the configuration of a network system constructed using a server equipped with the notation conversion device according to the present embodiment.
As shown in FIG. 2, the network system is constructed by connecting a server 20 and a plurality of clients (terminal devices) 40 to a network 30. Thereby, it is possible to provide a service for supporting the development of an application by automatically converting the characteristic tree diagram or the UML notation into another notation for the user of the client 40.

  As shown in FIG. 2, the server 20 that provides the service includes a UML conversion unit 21, a UML description table consistency check unit (hereinafter abbreviated as “check unit”) 22, a characteristic tree display unit 23, and a characteristic tree conversion unit 24. , And a UML display unit 25, which can store a characteristic tree table 26 and a UML description table 27. As hardware, for example, an auxiliary storage device such as a CPU, a semiconductor memory, and a hard disk device, and a network control unit that transmits and receives data via the network 30 are provided. The tables 26 and 27 are stored in a semiconductor memory or an auxiliary storage device, and the units 21 to 25 are realized by, for example, the CPU executing a program stored in the auxiliary storage device.

Each of the tables 26 and 27 stores the following data.
FIG. 3 is a diagram for explaining the characteristic tree table. FIG. 3A is a diagram illustrating the data configuration of the characteristic tree table 26, and FIG. 3B is a diagram illustrating the data configuration of attributes stored for each characteristic. First, the characteristic tree table 26 will be described in detail with reference to FIG.

  The characteristic tree table 26 is for storing data obtained by performing the characteristic (function) analysis of the class. As shown in FIG. 3A, the domain name and the characteristic name are indexes. The domain name is input according to the domain analysis result. As the characteristic name, the name of the top-level characteristic when performing characteristic analysis is input.

  As the lower one level characteristic, a characteristic name obtained by dividing the uppermost characteristic into characteristics is input. The attribute of the characteristic, for example, item data (attribute data) as shown in FIG. 3B is input to the lower level attribute. Similarly, a characteristic name obtained by dividing the upper characteristic into characteristics and the attribute data shown in FIG. 3B are input to the lower two-level characteristic, the lower two-level attribute, the lower n-level characteristic, and the lower n-level attribute. For convenience, the characteristic name and attribute data stored for each characteristic will be collectively referred to as “characteristic definition data”.

  As an item indicating an attribute, as shown in FIG. 3B, classification, lower level map, reuse group name, non-functional characteristics, request level, stability, UML description upper / lower level map, class attribute / method, etc. Is prepared. Each item stores the following data.

  In the classification, data indicating the characteristic to which the characteristic belongs is stored. Here, for the sake of convenience, only two characteristics are assumed: a common characteristic that does not depend on the application or a rare characteristic, and a variable characteristic that is an ordinary characteristic that depends on the application.

  The lower level map stores data indicating the relationship with the characteristic located below the characteristic. The reuse group name stores data that uniquely indicates a group (reuse group) to which the characteristic belongs. Non-functional characteristics store data indicating required characteristics related to quality such as performance, memory capacity, and reliability. In the request level, data indicating the request level for the request characteristic indicated by the non-functional characteristic data is stored. The degree of request is selected from, for example, essential, conditional mandatory, unnecessary, or proposal level.

In stability, data indicating the degree of possibility that the required characteristic is changed is stored. The degree is represented by, for example, large, medium, or small.
In the present embodiment, the UML obtained by converting the characteristic tree diagram can be changed. The UML description upper / lower map is an item prepared for this purpose. In the item, when the upper or lower map is changed on the UML, data indicating the change contents is stored. Thereby, the data is stored as necessary when the changed UML is converted into a characteristic tree diagram.

  Class attributes and methods are items prepared assuming that UML is converted into a characteristic tree diagram. The items store data corresponding to class attributes and methods in UML. The data is stored separately so that class attributes and methods can be identified.

  In the characteristic tree table 26 having the data structure as described above, one or more characteristics are associated with a lower level of the characteristic not located at the lowest level. Thereby, the table 26 describes a characteristic tree diagram as shown in FIG.

  FIG. 4 is a diagram for explaining an example of data storage in the characteristic tree table. FIG. 4A is a diagram illustrating an example of data stored in the characteristic tree table 26, and FIG. 4B is a diagram illustrating an example of data stored as an attribute of the characteristic name “OS2K save”. FIG. 4A shows only classification data as attribute data. The characteristic names “OS2K save” and “OS95 save” are class characteristic names for saving files by the OSs OS2K and OS95, respectively. When data as shown in FIG. 4 is stored in the characteristic tree table 26, a characteristic tree as shown in FIG.

The conversion of the characteristic tree diagram into UML is performed with reference to the characteristic tree table 26 described above. The UML description table 27 is generated by performing the conversion.
FIG. 5 is a diagram for explaining the UML description table. FIG. 5A is a diagram for explaining the data structure of the UML description table 27, and FIG. 5B is a diagram for explaining the data structure of attributes stored in the table 27. Next, the UML description table 27 will be specifically described with reference to FIG.

  In the UML description table 27, data of each item of type, class name / note name, class attribute, method, and attribute is stored in each record. Each item stores the following data.

  In the UML description table 27, a record is prepared for each class and note. In the type, data indicating any one of classes and notes is stored so that the data stored in the record can be identified. In the class name / note name, the class of the type indicated by the data or the name of the note is stored.

  The class attribute stores the data included in the class standard notation in UML. The method stores the data included in the class standard notation in UML. These data are stored as data of class attributes / methods shown as items in FIG. 3B when converted into a characteristic tree diagram.

  The attributes include, for example, item data (attribute data) as shown in FIG. 5B, that is, classification, upper level, lower level map, characteristic tree lower level map, reuse group name, non-functional characteristics, requirement level, and stability. Data of items such as, is stored. In the upper and lower maps, data indicating the names of classes located at the upper and lower levels of the level and the relationship with the names (for example, generalization, composition, or note anchor) are stored. In the characteristic tree lower map, data of the lower map shown as items in FIG. 3B is stored. By storing the data, if a special map expression is performed in the characteristic tree diagram represented by the characteristic tree table 26, the expression is reflected in the UML. Since other items are the same as those in the characteristic tree table 26, the description thereof is omitted.

  By storing data indicating either a class or a note in the above type, a record is prepared in the UML description table 27 for each characteristic and characteristic attribute shown in the characteristic tree diagram. , And UML specific data is stored. Thus, if the characteristic tree diagram is as shown in FIG. 1A, data that can represent the class diagram as shown in FIG.

  FIG. 6 is a diagram for explaining an example of data storage in the UML description table. 6A is a diagram for explaining an example of data stored in the UML description table 27. FIG. 6B is a diagram illustrating each item of the attribute stored according to the characteristic of the characteristic name “OS2K save” (“OS2k class attribute” in the figure). FIG. 6C is a diagram for explaining an example of data of “item” (noted “item”). FIG. 6C shows each item of the attribute stored as the attribute of the property of the property name “OS2K save” (denoted “OS2k note attribute item” in the figure) It is a figure explaining the example of data.

  The data storage example shown in FIG. 6 is for the case where the data shown in FIG. 4 is stored in the characteristic tree table 26. By storing data as shown in FIG. 6 in the UML description table 27, a class diagram as shown in FIG. 11 is displayed from the table 27.

  The automatic conversion of the characteristic tree diagram to UML is performed by the user of the client 40 specifying the storage location of the characteristic tree table 26 and the storage location of the UML description table 27 generated by the automatic conversion, for example. The reverse is also true.

  The UML conversion unit 21 shown in FIG. 2 automatically converts a characteristic tree diagram into UML by generating a UML description table 27 with reference to the characteristic tree table 26 described above. It is activated by an activation request from the client 40. The activated conversion unit 21 performs the automatic conversion by executing the UML conversion process shown in FIG. Here, the conversion process will be described in detail with reference to FIG.

  First, in step S1, a record is secured in the UML description table 27 for each characteristic and attribute represented by the characteristic tree table 26, and data is stored in each item of type and class name / note name. Thereby, in the characteristics, data indicating the class as the type and data indicating the characteristic name as the class name / note name are stored. In the attribute, data indicating a note as a type and data indicating a characteristic name as a class name / note name are stored. After the storage of these data is completed, the process proceeds to step S2.

  In step S2, paying attention to the characteristics constituting the reuse group, the class attribute, upper level, and lower level map data of the corresponding record are stored. In the class attribute, for each reuse group represented by the characteristic tree table 26, the highest characteristic is detected in the group, and the name of the detected characteristic is stored as data. In the upper and lower maps, data corresponding to the positional relationship of the characteristics from the lowest characteristic of the reuse group is stored. More specifically, if there is a characteristic located at the upper level, the characteristic name and generalization (indicated as “upper characteristic name: generalization” in the figure) are stored as data. If there is a characteristic located at a lower level, the characteristic name and generalization (indicated as “lower characteristic name: generalization” in the figure) are stored as data. If data exists in the UML description upper / lower map, which is an attribute item of the characteristic tree table 26, it is stored as upper / lower map data.

  In step S3 following step S2, paying attention to the attribute of the characteristic, data is stored in the corresponding record. As the data of the upper and lower maps, the name of the characteristic and the note anchor (denoted as “the characteristic name: note anchor” in the figure) are stored. Further, the data of each item of the classification, the lower level map, the reuse group name, the non-functional characteristic, the request level, the stability, and the class attribute / method is read from the characteristic tree table 26 and stored as the corresponding item data. . The process proceeds to step S4 after the storage is completed.

  In step S4, focusing on the exclusion characteristic, the data of the corresponding record is stored. In the upper and lower maps, data corresponding to the positional relationship of the characteristics from the lowest characteristic in the characteristic tree diagram is stored. More specifically, if there is a higher-order characteristic, the characteristic name and composition (indicated as “upper characteristic name: composition” in the figure) are stored as data. If there is a characteristic located at a lower level, the characteristic name and generalization (indicated as “lower characteristic name: generalization” in the figure) are stored as data. If data exists in the UML description upper / lower map, which is an attribute item of the characteristic tree table 26, it is stored as upper / lower map data.

  In step S5 following step S4, attention is paid to the characteristics higher than the highest characteristics in the reuse group, and data of corresponding records is stored. In the class attribute, the highest level characteristic among the characteristics of interest is detected in consideration of the hierarchical relationship, and the name of the detected characteristic is stored as data. In the upper and lower maps, data corresponding to the positional relationship of the characteristic from the lowest characteristic in the characteristic of interest is stored. More specifically, the name of the detected characteristic and generalization (indicated as “upper characteristic name: generalization” in the figure) are stored as the characteristic data located at the upper level, and the characteristic data located at the lower level is stored. , The characteristic name, and generalization (denoted as “lower characteristic name: generalization” in the figure). After the storage is completed, the generated UML description table 27 is stored in the designated storage location, and then a series of processing ends.

  The UML display unit 25 shown in FIG. 2 generates display image data from the UML description table 27 generated as described above or the UML description table 27 specified by the user of the client 40 and transmits it to the client 40. Is. By transmitting the image data, a UML (here, a class diagram) as shown in FIG. 1B or FIG. 11 is displayed on the display device that the client 40 has or is connected to.

  The UML description table 27 can be updated by the client 40. The check unit 22 shown in FIG. 2 automatically checks the consistency in the contents of the updated table 27. It is activated by an activation request from the client 40. The activated check unit 22 performs a consistency check on the UML description table 27 designated by the client 40, for example. This check is performed by executing the UML description table consistency check process shown in FIG. Here, the checking process will be described in detail with reference to FIG.

In the check process, by executing step S11, consistency check focusing on the following check items is performed, the result is transmitted to the client 40, and the process ends.
(1) Whether or not a class name and a note name are paired (records are prepared for the characteristics and their attributes, respectively. For characteristics having attributes, the same characteristic name is the class name / note name data. And there are two records whose type data is class and note)
(2) Whether the relationship is a note anchor in the upper and lower map data of the record whose type data is a note (3) The upper and lower map of the record whose type data is a class The relationship between the data indicating the higher class (characteristics) is generalized, there is no higher-level class that has the composition, and the classification in the record of the corresponding note is repeated. Whether or not it is a characteristic that can be used (in this case, the common characteristic is equivalent) (4) Among the records in which the type of data is a class, the relationship between the data indicating the upper class of the upper and lower maps Whether the classification in the record of the corresponding note is a non-reusable characteristic (in this case, the variable characteristic is equivalent) And whether or not the classification in the lower class record of the upper and lower maps is the characteristic. (5) The classification of the record in which the type data is a note is a reusable characteristic. Whether the reuse group name is the same among the generalized classes in the class in which the relationship of the data indicating the upper or lower class of the upper or lower map is generalized (6) Whether or not the number of records whose type data is a note matches the number of attribute of the characteristic in the corresponding characteristic tree table 26. Show. The inconsistency results in that conversion to the characteristic tree diagram (characteristic tree table 26) cannot be performed, or the conversion is inappropriate. Therefore, in this embodiment, a check is performed for each check item, and the check result is transmitted to the client 40 side. As a result, if a mismatch is found by the check, a message indicating that fact and detailed information about the mismatch are transmitted to the client 40. For this reason, the user of the client 40 can easily confirm whether or not the update to the UML description table 27 is appropriately performed. The check process ends after such data transmission is performed in step S11.

  The characteristic tree conversion unit 24 shown in FIG. 2 automatically converts the UML into a characteristic tree diagram by generating the characteristic tree table 26 with reference to the UML description table 27 described above. It is activated by an activation request from the client 40. The activated conversion unit 24 performs the automatic conversion by executing the characteristic tree conversion process shown in FIG. Here, the conversion process will be described in detail with reference to FIG.

  First, in step S21, for a record whose type in the UML description table 27 is a class, a class whose relationship with the lower class is generalized by referring to the upper and lower map data. The top-level class is detected, the tree structure is constructed from the data, and the lower-level map data is generated.

  In the structure of the tree structure, the difference in relation, that is, whether it is generalization or composition, is ignored. Due to the structure of the tree structure, necessary records are secured in the property tree table 26, and the property name of the class name / note name and the data of the lower map are stored as property names in the secured record. As the class attribute / method data of the record, the class attribute and method data of the record whose type is class are stored. After storing them, the process proceeds to step S22.

  In step S22, as the attribute data of the secured record, the same property name is stored in the class name / note name, and the attribute data of the record whose type is a note, that is, classification, property tree lower map, reuse group name, Read and store data for each item of non-functional characteristics, required level, and stability. After the storage is performed for each record, a series of processing is terminated.

  The characteristic tree display unit 23 shown in FIG. 2 generates image data for display from the characteristic tree table 26 generated as described above or the table 26 specified by the user of the client 40 and transmits it to the client 40. Is. By transmitting the image data, a characteristic tree diagram as shown in FIG. 1A or FIG. 10 is displayed on the display device that the client 40 has or is connected to.

  In the present embodiment, the notation conversion device mounted on the server 20 can perform both automatic conversion from the characteristic tree diagram to UML and automatic conversion from UML to the characteristic tree diagram. Only one of these may be performed. The server 20 is also equipped with a consistency check device that checks the consistency of UML data, but may be installed in another device. The same applies to the notation conversion device.

  A program for realizing the notation conversion device or the consistency check device as described above may be recorded and distributed on a recording medium such as a CD-ROM, a DVD, or a removable flash memory. Part or all of the program may be distributed via the network 30. In such a case, the user can apply the present invention to the device by acquiring the program and loading it into the data processing device. Therefore, the recording medium may be accessible by a device that distributes the program.

It is a figure explaining the conversion object in this Embodiment. It is a figure explaining the structure of the network system constructed | assembled using the server carrying the notation conversion apparatus by this Embodiment. It is a figure explaining a characteristic tree table. It is a figure explaining the example of data storage to a characteristic tree table. It is a figure explaining a UML description table. It is a figure explaining the example of data storage to a UML description table. It is a flowchart of a UML conversion process. It is a flowchart of a UML description table consistency check process. It is a flowchart of a characteristic tree conversion process. It is a figure explaining the example of a characteristic tree display. It is a figure explaining the example of UML display. It is a figure explaining the UML notation by the prior art described in patent document 3. FIG.

Explanation of symbols

20 server 21 UML conversion unit 22 UML description table consistency check unit 23 characteristic tree display unit 24 characteristic tree conversion unit 25 UML display unit 26 characteristic tree table 27 UML description table 30 network 40 client

Claims (9)

A device that performs automatic conversion between data expressed in different notations related to the development of application programs,
Data acquisition means for acquiring hierarchical diagram data indicating a functional hierarchical diagram that can be extracted by domain analysis as the data;
Conversion means for automatically converting the hierarchy diagram data acquired by the data acquisition means to generate UML data expressed in UML;
A notation conversion device comprising: Checking means for checking consistency in the UML data;
The notation conversion device according to claim 1, further comprising: Other conversion means for automatically converting the UML data to generate the hierarchy diagram data,
The notation conversion device according to claim 1, further comprising: The check means performs a consistency check in consideration of automatic conversion of the UML data into the hierarchy diagram data;
The notation conversion device according to claim 3. A device that performs automatic conversion between data expressed in different notations related to the development of application programs,
Data acquisition means for acquiring UML data written in UML as the data;
Conversion means for automatically converting the UML data acquired by the data acquisition means to generate hierarchical diagram data indicating a functional hierarchy diagram that can be extracted by domain analysis;
A notation conversion device comprising: An apparatus mounted for checking data consistency in the notation conversion apparatus according to claim 1 or 5,
Data acquisition means for acquiring UML data written in UML as the data;
Check means for checking the consistency of the UML data acquired by the data acquisition means;
A consistency check apparatus comprising: A program to be executed by a notation conversion device that performs automatic conversion between data expressed by different notation methods related to application program development,
A function of acquiring hierarchical diagram data indicating a functional hierarchical diagram that can be extracted by domain analysis as the data;
A function of automatically converting the hierarchical diagram data obtained by the function to obtain and generating UML data represented in UML;
A program to realize A program to be executed by a notation conversion device that performs automatic conversion between data expressed by different notation methods related to application program development,
A function of acquiring UML data expressed in UML as the data;
A function of automatically converting UML data acquired by the function to be acquired and generating hierarchical diagram data indicating a functional hierarchical diagram that can be extracted by domain analysis;
A program to realize A program to be executed by a consistency check device mounted for checking data consistency in the notation conversion device according to claim 1 or 5,
A function of acquiring UML data expressed in UML as the data;
A function for checking the consistency of UML data acquired by the function to be acquired;
A program to realize

Images