Part definition information management system and part definition information management method

Abstract

To achieve the reuse of a component suitable for business characteristics by making it possible to discriminate what business a designed component is designed for when a GUI developer reuses the designed component.SOLUTION: A component definition information management system acquires component definition information and component applications, associates the component definition information with the component applications, analyzes a common rate of contents of the component definition information in the unit of the component applications, gives an abstraction degree about threshold evaluation of the common rate to the component definition information on the basis of an analysis result, sets a threshold to be a reference to give the abstraction degree, acquires business information about business in selecting the component definition information, retrieves the component definition information associated with the component applications corresponding to the character string included in the acquired business information, acquires hit component definition information and an abstraction degree given to the hit component definition information, and outputs the acquired component definition information and abstraction degree.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] The present invention relates to a part definition information management system and a part definition information management method. [Background technology]

[0002] In recent years, the development of digital solutions to improve inefficient business processes through digital transformation (DX) has become increasingly common. One method of digital solution development is to develop applications that improve existing business processes and then deploy them in the workplace, aiming to improve productivity. Some applications used in business operations feature a graphical user interface (GUI). For example, a production management dashboard application that visualizes production line status, such as manufacturing delays and material shortages, includes a dashboard that displays a summary of the production line status to the user and a detailed screen that displays the breakdown of the production line. In this way, the GUI serves as the interface between the application and the user. Therefore, poor GUI design can lead to reduced productivity, making GUI design important when deploying the application in the workplace. However, GUI design is difficult to describe as software requirements, which can lead to rework after development and increase the amount of time developers spend on completing the GUI.

[0003] Therefore, prototyping, which is used to create and improve GUIs, can help developers align their goals with those of their application users. For example, by quickly developing a GUI for an application to be implemented in a business process and showing it to the user while interviewing the user about the application's business operations, developers can confirm early on whether the GUI they are developing matches the business characteristics. However, developing a GUI from scratch is difficult because it places a heavy burden on the developer and requires a lot of time and effort. To alleviate this burden, developers can reuse pre-designed GUI components. Because the buttons and cards that make up a GUI can be shared across multiple GUIs, reusing pre-designed components can reduce labor costs. However, to reuse components, developers must prepare pre-designed components and assign names to each component. For example, if a component is a "button" in a GUI, the component can be named "Button." If there are multiple components of the same type, they can be distinguished by assigning different numbers to each component, such as "Button 1," "Button 2," and so on. This allows developers to find components by their assigned names when reusing them. However, it is difficult to understand the actual components from a name based on the component's type. For this reason, in the past, developers could not determine whether a component could be reused based on its name. To confirm the actual GUI represented by the component, developers had to perform the extra step of displaying the GUI on the screen and then directly specifying and calling the component on the screen. Therefore, efficient component reuse requires component management that allows developers to easily determine whether a component can be reused. Patent Document 1 (JP-A-2005-102526) addresses this issue. Patent Document 1 states: "Components that make up a screen are assigned names that represent the component settings for specific items set for that component. In other words, names that reflect the screen designer's thinking when configuring the components are assigned. This makes it easier to understand the correspondence between components and their names and to associate the component's actual entity with the name, compared to when a uniform name is assigned based solely on the component's type."Furthermore, if priorities are set for the items that are the basis for generating names, it is possible to realize automatic naming that is similar to naming done by the screen creator himself." [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Application Publication No. 8-212242 Summary of the Invention [Problem to be solved by the invention]

[0005] In Patent Document 1, components are assigned names that represent specific pre-defined items, making it possible to understand the entity of the component. This allows developers to reuse components by referencing the component names. However, when deciding whether to reuse a component, developers are unable to determine the type of business the component is designed for, which makes it inconvenient when developing a GUI tailored to the characteristics of that business. While prior art allows components to be reused by referencing the name based on the GUI's shape, color, and function, it is impossible to determine the type of business the component is intended to be used for. For example, when developing a GUI login screen, authentication may be performed using an ID and password or an external account, and the components that make up the GUI may differ. Therefore, it is necessary to be able to identify components according to their intended use.

[0006] The present invention has been made in view of the above-mentioned problems, and aims to enable a developer to determine the type of business for which a designed component is designed when reusing the component, thereby realizing the reuse of components suited to the characteristics of the business. [Means for solving the problem]

[0007] According to a first aspect of the present invention that solves the above problem, there is provided a component definition information management system as follows. The component definition information management system is a system that selects component definition information. The component definition information management system includes a component definition information input unit, a component use input unit, a registration unit, an analysis unit, an abstraction level classification unit, a threshold setting unit, a business information input unit, a search unit, and an output unit. The component definition information input unit acquires component definition information. The component use input unit acquires component uses. The registration unit links the component definition information with the component uses. The analysis unit analyzes the commonality of the content of the component definition information for each component use. The abstraction level classification unit assigns an abstraction level related to a threshold evaluation of the commonality level to the component definition information based on the analysis result of the analysis unit. The threshold setting unit sets a threshold that serves as a standard for the abstraction level assignment by the abstraction level classification unit. The business information input unit acquires business information related to the business when selecting component definition information. The search unit searches for component definition information associated with a component use corresponding to a character string included in the acquired business information, and acquires the component definition information and the abstraction level assigned thereto when found. The output unit outputs the component definition information and the abstraction level acquired by the search unit.

[0008] According to a second aspect of the present invention that solves the above-mentioned problems, there is provided a component definition information management method as follows: The component definition information management method is a method for selecting component definition information, and is performed using a processor, a storage unit, an input device, and a display device. The processor acquires component definition information and component uses, creates a component use table linking the component definition information with the component uses, stores the table in the storage unit, analyzes the commonality of the content of the component definition information for each component use, and based on the analysis results, creates an abstraction level table used to assign an abstraction level to the component definition information related to a threshold evaluation of the commonality level, sets a threshold value as a reference for assigning the abstraction level, acquires task information related to a task entered by a user via the input device when selecting the component definition information, searches the storage unit for component definition information linked to a component use corresponding to a character string included in the acquired task information, acquires the found component definition information and the assigned abstraction level, and outputs the acquired component definition information and the abstraction level to the display device. [Effects of the Invention]

[0009] According to the present invention, when a developer reuses a component that has already been designed, it is possible to determine the type of business for which the component was designed, thereby realizing the reuse of components that suit the characteristics of the business. Note that problems, configurations, and effects other than those described above will become clear from the following description of the embodiment of the invention. [Brief explanation of the drawings]

[0010] [Figure 1] 3A to 3C are diagrams illustrating an example of part definition information and a GUI according to the first embodiment. [Figure 2] FIG. 2 is a diagram illustrating an example of a functional configuration of a part definition information management system according to the first embodiment. [Figure 3] FIG. 2 is a diagram illustrating an example of a production management dashboard in the first embodiment. [Figure 4] FIG. 3 is a diagram illustrating an example of a part use storage unit in the first embodiment. [Figure 5] FIG. 3 is a diagram illustrating an example of an abstraction level storage unit in the first embodiment. [Figure 6] FIG. 4 is a diagram showing a specific example of part definition information in the first embodiment. [Figure 7] 4 is an example of a flowchart showing the flow of processing by an analysis unit in the first embodiment. [Figure 8] 10 is a flowchart illustrating an example of a processing flow of an abstraction level classification unit in the first embodiment. [Figure 9] FIG. 3 is a diagram illustrating an example of a threshold setting unit in the first embodiment. [Figure 10] FIG. 10 is a diagram illustrating an example of a functional configuration of a part definition information management system according to a second embodiment. [Figure 11] 10 is an example of a screen display in the second embodiment. [Figure 12] 10 is an example of a flowchart showing the flow of processing by a part extraction unit in the second embodiment. [Figure 13] FIG. 11 is a diagram illustrating an example of a functional configuration of a part definition information management system according to a third embodiment. [Figure 14]FIG. 13 is a diagram illustrating an example of a functional configuration of a part definition information management system according to a fourth embodiment. [Figure 15] FIG. 13 is a diagram illustrating an example of a weight setting unit in the fourth embodiment. [Figure 16] FIG. 13 is a diagram showing an example of a screen for inputting weighting settings in the fourth embodiment. [Figure 17] FIG. 2 is a diagram illustrating an example of computer hardware for implementing a part definition information management system. DETAILED DESCRIPTION OF THE INVENTION

[0011] The following describes embodiments using the drawings. Note that the following is merely an example of implementation, and the invention itself is not intended to be limited to the specific contents described below. In the following description, identical or similar elements and processes may be designated by the same reference numerals, and redundant explanations may be omitted. In later embodiments, only differences from previous embodiments may be described, and redundant explanations may be omitted. In addition, the following description of the embodiments and the configurations and processes shown in the drawings provide an overview of the embodiments to the extent necessary for understanding and implementing the present invention, and are not intended to limit the implementation aspects of the present invention. In addition, each embodiment and each modified example may be combined in part or in whole within a range that is consistent with each other without departing from the spirit of the present invention.

[0012] First Embodiment This embodiment shows a process for selecting components suitable for business information when a developer wants to reuse already-designed components in GUI development, and for allowing the developer to select the components to reuse from the selection results. This embodiment consists of two phases: a registration phase for registering already-designed components in preparation for reuse, and a search phase for searching for components to be reused.

[0013] Here, we will explain examples of GUIs that developers develop by reusing components that have already been designed. GUI example 101(a) shown in Figure 1 is a GUI used for work that requires logging in using an ID and password, and has an ID input form and a password input form, with a login button at the bottom. GUI example 101(b) is a GUI used for work that requires logging in using external account integration, and has a card that shows which external account it is, with a login button to the right of that.

[0014] As such, there are tasks that require login, such as using an ID and password or linking to an external account, and the types of buttons, input forms, cards, etc. included in the GUI vary depending on the task. Therefore, when reusing designed components, it is necessary to use different GUIs depending on the task, so in this embodiment, the GUIs are managed collectively for each task. Information that determines the shape, size, placement, color, function, etc. of GUI components to realize such GUI management is defined as component definition information 100.

[0015] Component definition information 100 will be described with reference to FIG. 1. FIG. 1 is a diagram showing an example of component definition information 100 according to this embodiment. Examples 100(a) and 100(b) of component definition information 100 describe the shape, size, placement, color, function, and other specifications of GUI components. Component definition information example 100(a) describes information about buttons and forms in GUI example 101(a). A button consists of parameters such as setType, which defines the type; setView, which defines the character string or image to be displayed; setEvent, which defines the function; shape, which defines the shape; size, which defines the size; placement, color, which defines the color; and font, which defines the font. Setting each parameter allows a button on the GUI to be defined. The input form in component definition information example 100(a) consists of parameters such as setType, which defines the type; setView, which defines the character string or image to be displayed; setEvent, which defines the function; shape, which defines the shape; size, which defines the size; placement, color, which defines the color; and font, which defines the font. Setting each parameter allows an input form on the GUI to be defined.

[0016] Note that the GUI for a task that requires login using an ID password is configured with a combination of buttons and input forms, so the buttons and input forms are described together. For example, in component definition information example 100(a), the descriptions of the buttons and input forms are enclosed in the symbols " / / ID password" so that it is clear that they are for the GUI for a task that requires login using an ID password. In this embodiment, such symbols are defined as start and end symbols.

[0017] The start and end symbols are used by the developer of the component definition information 100 to indicate to others what business the description is for, and include a character string that expresses the business. In this embodiment, candidate character strings that include the start and end symbols are prepared in advance, and the start and end symbols are written using the candidate character strings. This allows multiple people to share a common understanding.

[0018] In addition, in the component definition information 100(b), the button and card are surrounded by the start and end symbols " / / external account linkage" to indicate that the description is for a business operation that requires logging in using external account linkage.

[0019] Typically, both the start and end symbols of " / / ID password" and " / / external account linkage" and the enclosed descriptions are included in the same component definition information 100. On the other hand, a developer reusing components may want to reuse a GUI corresponding to either " / / ID password" or " / / external account linkage," or a GUI corresponding to both, depending on the business of the user who will operate the application being developed. For example, if the business of the user who will operate the application being developed does not require logging in using an external account, the developer may want to reuse only the GUI corresponding to " / / ID password." Furthermore, the criterion for determining whether a GUI is generally required for the business may be used as a criterion for reuse. In particular, when a developer develops a GUI through prototyping, the developer wants to speed up development by reusing a general-purpose GUI. For example, in the GUI of a login screen, " / / ID password" can be considered general-purpose.

[0020] To accommodate such different GUI usages, combinations of start and end symbols are considered. For example, in the case of component definition information 100 having two start and end symbol combinations, " / / ID password" and " / / external account linkage," the component definition information 100 has three start and end symbol combinations: " / / ID password" only, " / / external account linkage" only, " / / ID password" and " / / external account linkage." In this embodiment, a method is considered for reusing the component definition information 100 while making it possible to distinguish the versatility of the GUI by utilizing such start and end symbol combinations.

[0021] From this perspective, in this embodiment, a component definition information management system 200 that manages the component definition information 100 so that components can be reused based on differences in business will be described.

[0022] An example of the functional configuration of the component definition information management system 200 according to the present embodiment will now be described with reference to Fig. 2. Fig. 2 is a diagram showing an example of the functional configuration of the component definition information management system 200 according to the first embodiment. As shown in Fig. 2, the component definition information management system 200 includes a component definition information input unit 201, a component use input unit 202, a registration unit 203, a storage unit 204, an analysis unit 205, an abstraction level classification unit 206, a threshold setting unit 207, a task information input unit 208, a search unit 209, and an output unit 210. The storage unit 204 includes, as storage areas, a component definition information storage unit 204-1, a component use storage unit 204-2, and an abstraction level storage unit 204-3. The component definition information storage unit 204-1 holds a plurality of pieces of component definition information 100.

[0023] First, the component definition information input unit 201 will be described. In the registration phase, the component definition information input unit 201 accepts input of already-designed component definition information 100 in preparation for reuse. The input component definition information 100 is stored in the component definition information storage unit 204-1. The component definition information 100 may be input into the component definition information input unit 201 by a developer's operation or automatically input from a program. In the following embodiments, input by a developer's operation will be described. Note that in this embodiment, a case will be described in which the component definition information 100 is input as a text file.

[0024] In the registration phase, the part use input unit 202 accepts input of the part use of the part definition information 100 input to the part definition information input unit 201. In this embodiment, the part use is defined as a character string representing the use of the part definition information 100. For example, the production management dashboard example shown in FIG. 3 has screen transitions of a login screen 300, a dashboard screen 301, and a details screen 302. First, the login screen 300 is a screen for logging in using an ID and password. Pressing the Login button on the login screen 300 transitions to the dashboard screen 301. Here, a summary of the production line status is displayed, and in this example, the number of production lines where work is delayed is shown. Furthermore, if the user wants to know the breakdown of the delayed production lines, pressing the details button displays a details screen 302 showing details of the production lines. This allows the user to confirm that the actual delayed production lines are Line A and Line B. In such a dashboard, examples of character strings indicating the component usage may be "login" for the login screen 300, "dashboard" for the dashboard screen 301, and "details" for the details screen 302.

[0025] The registration unit 203 stores the component definition information 100 input to the component definition information input 201 in the storage unit 204. The registration unit 203 also creates a component usage table that links the component definition information 100 with the component usage input to the component usage input unit 202, and stores the table in the storage unit 204.

[0026] As described above, the storage unit 204 includes the component definition information storage unit 204-1, the component use storage unit 204-2, and the abstraction level storage unit 204-3. Here, the information of the component use storage unit 204-2 in this embodiment will be described with reference to FIG. 4. FIG. 4 is a diagram showing an example of information stored in the component use storage unit 204-2 in the first embodiment. As shown in FIG. 4, the component use storage unit 204-2 stores a component use table 400 created by the registration unit 203, which links component uses with component definition information 100. The component definition information 100 linked to the component uses is stored in the component definition information storage unit 204-1 shown in FIG. 2. As shown in FIG. 4, multiple pieces of component definition information 100 are linked to one component use and stored.

[0027] The analysis unit 205 compares the start and end symbols of the component definition information 100 associated with the component use stored in the component use storage unit 204-2 to calculate a commonality rate. In this embodiment, the commonality rate is a numerical value representing the proportion of component definition information 100 having a certain start and end symbol among the component definition information 100 associated with the same component use. When there are N pieces of component definition information 100 and M pieces of component definition information having a certain start and end symbol, the commonality rate is M / N*100%. When a certain start and end symbol is shared by all component definition information 100 associated with the same component use, the commonality rate is 100%.

[0028] The abstraction level classification unit 206 determines the abstraction level of the component definition information 100 from the commonality rate calculated by the analysis unit 205, creates an abstraction level table 500 that links and manages the component definition information 100 and the abstraction level, and stores the abstraction level table 500 in the abstraction level storage unit 204-3. Fig. 5 is an example of the abstraction level table 500. The abstraction level table 500 links the component definition information 100 stored in the component definition information storage unit 204-1 with the correspondence between combinations of start and end symbols that the component definition information 100 has, and manages each combination by linking it with an abstraction level.

[0029] For example, if the contents of file1 shown in Figure 5 are component definition information X in Figure 6, there are seven possible combinations of start and end symbols: "ID password" only, "multi-factor authentication" only, "calendar display" only, "ID password" and "multi-factor authentication," "ID password" and "calendar display," "multi-factor authentication" and "calendar display," and "ID password," "multi-factor authentication," and "calendar display." These combinations are managed by linking them to file1.

[0030] In this embodiment, the level of abstraction is defined as being high when a start and end symbol of component definition information 100 is shared by a large number of component definition information 100 that are linked to the same component use as the component definition information 100, and low when shared by a small number of component definition information 100. For example, in the example shown in Fig. 5, "ID password" is common to file1, file2, and file3, so the level of abstraction is "high," while "multi-factor authentication" is present in file1 but not common to file2 and file3, so the level of abstraction is "low."

[0031] For determining whether the level is high or low (i.e., for threshold evaluation), a threshold can be set by the threshold setting unit 207, and the abstraction level of component definition information 100 including start and end symbols with a commonality rate equal to or greater than the set threshold is set to "high," and the abstraction level of component definition information 100 including start and end symbols with a commonality rate less than the set threshold is set to "low." Furthermore, the abstraction level may be set to three levels, including "medium," or even more levels, instead of two levels, "high" and "low." In this embodiment, the abstraction level is described as being set to three levels: "high," "medium," and "low." Regarding the threshold for the commonality rate, a level of "high" is set to "high," a level of "medium" is set to "medium," and a level of "low" is set to "low."

[0032] The information stored in the abstraction level storage unit 204-3 in this embodiment will now be described. The abstraction level storage unit 204-3 stores an abstraction level table 400 created by the abstraction level classification unit 206 and shown in FIG. 5, which associates the component definition information 100 with the abstraction level. As described above, the associated component definition information 100 is stored in the component definition information storage unit 204-1 shown in FIG. 2. As shown in FIG. 5, for each piece of component definition information 100, an abstraction level such as "high," "medium," or "low" set by the threshold setting unit 207 is associated and stored based on the combination of its start and end symbols.

[0033] In the search phase, the business information input unit 208 accepts input of business information from a user (such as a developer) when searching to reuse the component definition information 100. In this embodiment, business information is a string of characters representing what is required for a business. For example, in the case of the production management dashboard example shown in FIG. 3, examples of business information include "log in to the system," "check the summary on the dashboard," and "check the breakdown of the production line in detail."

[0034] In the search phase, the search unit 209 uses the business information input to the business information input unit 208 to search the component use storage unit 204-2, and obtains the component definition information 100 and abstraction level table 500 associated with the found component use from the component definition information storage unit 204-1 and abstraction level storage unit 204-3, respectively. For example, if "log in to the system" is input as business information, the character string "login" therein will be found as a component use. If no component use is found, the developer who reuses the component is prompted to enter different business information, for example, via the display device 1706 described below.

[0035] The output unit 210 outputs the component definition information 100 and the abstraction level table 500 acquired by the search unit 209 in the search phase.

[0036] Here, the calculation of the commonality rate in the analysis unit 205 will be described with reference to Fig. 6 and Fig. 7. Fig. 7 is an example of a flowchart showing the flow of the commonality rate calculation process in the first embodiment. In the process of the flowchart in Fig. 7, the part definition information 100 stored in the part definition information storage unit 204-1 shown in Fig. 6 is used.

[0037] The processing of the analysis unit 205 is executed when the component definition information 100 is stored in the component definition information storage unit 204-1 (S701). For example, the newly stored component definition information is component definition information X shown in Fig. 6, and the already stored component definition information is component definition information Y1, component definition information Y2, and component definition information Y3 shown in Fig. 6.

[0038] Next, the analysis unit 205 analyzes the component definition information X and stores the start and end symbols (S702). For example, the analysis unit 205 stores the "ID password," "multi-factor authentication," and "calendar display" of the component definition information X shown in FIG.

[0039] Next, the analysis unit 205 refers to the component use storage unit 204-2 and acquires the component use linked to the component definition information X and the component definition information 100 linked to the same component use (S703). For example, the analysis unit 205 acquires the component definition information Y1, component definition information Y2, and component definition information Y3 shown in FIG. 6.

[0040] Next, one piece of component definition information is acquired from the component definition information to be compared (S704). For example, the component definition information Y1 shown in FIG. 6 is acquired. Next, the analysis unit 205 analyzes the component definition information 100 acquired in S704 and stores the start and end symbols (S705). For example, the analysis unit 205 stores "ID password," "multi-factor authentication," and "campaign display" of the component definition information Y1 shown in FIG. 6.

[0041] Next, the analysis unit 205 calculates the commonality rate of the start and end symbols stored in S702 and S705. For example, "ID password" and "multi-factor authentication" are common to both component definition information X and component definition information Y1, so the commonality rate is 100%, while "calendar display" and "campaign display" are listed in only one of component definition information X and component definition information Y1, so the commonality rate is 50%.

[0042] Next, it is determined whether any component definition information 100 to be compared remains (S707). If there is any component definition information 100 to be compared remains (S707-Yes), the next component definition information 100 to be compared is acquired (S708), and S705 is repeated until there is no more component definition information 100 to compare. In the next repetition, the commonality rate is recalculated for all previously stored start and end symbols. For example, if component definition information Y2 shown in FIG. 7 is acquired in the next repetition, "ID password," "external account linkage," and "news display" are stored in S705. Thereafter, when calculating the commonality rate in S706, the commonality rate is calculated for all of the previously stored "ID password," "multi-factor authentication," and "calendar display" of component definition information X and the "ID password," "multi-factor authentication," and "campaign display" of component definition information Y1. In the example, the commonality rate is recalculated as follows: "ID password" is common to all of component definition information X, component definition information Y1, and component definition information Y2, so the commonality rate is 100%; "multi-factor authentication" is common to component definition information X and component definition information Y1, but not to component definition information Y2, so the commonality rate is 66.6%; and "calendar display," "campaign display," "external account linkage," and "news display" are described in only one of component definition information X, component definition information Y1, and component definition information Y2, so the commonality rate is 33.3%.

[0043] Here, the determination of the level of abstraction of the component definition information 100 in the abstraction level classification unit 206 will be described with reference to Fig. 8. Fig. 8 is an example of a flowchart showing the flow of the abstraction level determination in the abstraction level classification unit 206 in the first embodiment. Fig. 9 is a diagram showing a specific example of the threshold setting unit 207 in the first embodiment. Fig. 9 will be used in the description of the flowchart in Fig. 8.

[0044] The processing of the abstraction level classification unit 206 is triggered by the completion of the commonality calculation processing of the analysis unit 205. First, the analysis unit 205 acquires the acquired component definition information 100 and newly stored component definition information 100 (S801). Thereafter, the newly stored component definition information 100 is included in the component definition information 100 acquired by the analysis unit 205.

[0045] Next, one piece of component definition information 100 is acquired (S802). Next, a combination of start and end symbols contained in the acquired component definition information 100 is calculated (S803). For example, in the case of component definition information X shown in FIG. 6, there are seven possible combinations of start and end symbols: "ID password" only, "multi-factor authentication" only, "calendar display" only, "ID password" and "multi-factor authentication," "ID password" and "calendar display," "multi-factor authentication" and "calendar display," and "ID password," "multi-factor authentication," and "calendar display."

[0046] Next, one of the combinations calculated in S803 is acquired (S804). For example, a combination containing only "ID / password" is acquired. Next, the commonality rate of the start and end symbols included in the acquired combination is acquired (S805). For example, in the case of only "ID / password," a commonality rate of 100% for "ID / password" is acquired. Next, the abstraction level is determined based on the threshold 800 shown in FIG. 9 set in the threshold setting unit 207 (S806). For example, as shown in FIG. 8, if the threshold is set so that a commonality rate of 60% or more is "high" for the abstraction level, a commonality rate of 30% or more is "medium" for the abstraction level, and a commonality rate of 0% or more is "low" for the abstraction level, the commonality rate of "ID / password" is 100%, so the combination containing only "ID / password" is determined to have a "high" abstraction level. At this time, if the combination contains multiple start and end symbols, the abstraction level is determined using the lowest commonality rate among the commonality rates of each start and end symbol.

[0047] Next, it is determined whether any combinations of start and end symbols remain that have not yet been acquired (S807). If any combinations of start and end symbols remain that have not yet been acquired (S807-Yes), the next combination of start and end symbols is acquired (S808), and S805 is repeated until all combinations of start and end symbols remain that have not yet been acquired. Next, it is determined whether any component definition information 100 remains that have not yet been acquired (S809). If any component definition information 100 remains that have not yet been acquired (S809-Yes), the next component definition information 100 is acquired (S810), and S803 is repeated until all component definition information 100 remains that have not yet been acquired. Information linking the abstraction level determined by the abstraction level classification unit 206 with the component definition information 100 is stored in the abstraction level storage unit 2043, using the abstraction level table 500 shown in FIG. 5 as an example.

[0048] According to this embodiment, when reusing designed components in GUI development, it is possible to select appropriate component definition information for the business information input into the component definition information management system 200, which reduces the man-hours required for GUI development. In addition, by assigning a level of abstraction, it is possible to determine the versatility of components, enabling the reuse of designed components tailored to the business, which can contribute economically.

[0049] Second Embodiment In the first embodiment, a method was shown that enables the determination of the versatility of a part by assigning a level of abstraction. In this embodiment, a method is shown that not only enables the determination of versatility by assigning a level of abstraction, but also outputs only the necessary part definition information 100 by specifying a part of the part definition information 100.

[0050] First, an example of the functional configuration of the part definition information management system 200(a) in this embodiment will be described with reference to Fig. 10. Fig. 10 is a diagram showing an example of the functional configuration of the part definition information management system 200(a) in the second embodiment. Compared to Fig. 1, which is a functional configuration diagram of the part definition information management system 200 in the first embodiment, it differs in that it includes a designation unit 1000 and a part extraction unit 1001, but is otherwise the same.

[0051] In the first embodiment, a method was described in which component definition information 100 and abstraction level table 500 were output to output unit 210 from the search results of search unit 209. However, in this embodiment, a part of component definition information 100 is specified by designation unit 1000 from component definition information 100 in the search results of search unit 209, and component extraction unit 1001 extracts the part of component definition information 100 and outputs it to output unit 210. This makes it possible for a developer to specify a part of component definition information that he or she wants to use from the search results of search unit 209, and extract and output that part. Only this difference will be described below.

[0052] The specification unit 1000 specifies a portion of the component definition information 100 to be output from the component definition information 100 that is the search result of the search unit 209. For example, in order to prompt the developer to specify a portion of the component definition information 100 to be output, the component definition information 100 and abstraction level table 500 that are the search result of the search unit 209 are formatted so that they are easy for the developer to view, and are displayed on the screen of a display device 1706 (described later) connected to the output unit 210, as shown in a search result display screen 1100 in FIG.

[0053] 11 is a screen on which a GUI developer can select the component definition information 100 and its abstraction level that he or she wishes to reuse using an input device 1705 (described later) connected to the designation unit 1000. The developer can make the selection by, for example, clicking the mouse.

[0054] When a developer selects component definition information 100 and its level of abstraction, a GUI configured by the component definition information 100 can be displayed as shown in preview display 1101, allowing the developer to check it. After confirming in preview display 1101 that the developer wants to use the component, the developer can select the component definition information 100 and its level of abstraction to be output from search result display screen 1100 in Fig. 11, and the specification unit 1000 specifies the start and end symbols of the component definition information 100 linked to the abstraction level table 500 based on the selection.

[0055] The component extraction unit 1001 extracts a part of the component definition information 100 from the search results of the search unit 209 based on the designation of the designation unit 1000 .

[0056] Here, the processing of the component extractor 1001 will be described with reference to Fig. 12. Fig. 12 is an example of a flowchart showing the flow of processing of the component extractor 1001 in the second embodiment.

[0057] The process in Fig. 12 is executed when the specification unit 1000 specifies start and end symbols for the component definition information 100. First, the specification unit 1000 acquires the component definition information for which the start and end symbols are specified (S1201). Next, the specification unit 1000 acquires one start and end symbol specified (S1202). Next, the specification unit 1000 acquires one start and end symbol from the component definition information acquired in S1201 (S1203).

[0058] Next, it is determined whether the specified start / end symbol acquired in S1202 matches the start / end symbol acquired in S1203 (S1204). If they do not match the specified start / end symbol (S1204-No), the next start / end symbol is acquired (S1205). If they match the specified start / end symbol (S1204-Yes), the description enclosed by the start / end symbols is stored (S1206).

[0059] Next, it is determined whether there are any start and end symbols that have not yet been acquired (S1207). If there are any start and end symbols that have not yet been acquired (S1207-Yes), the next start and end symbol is acquired (S1208), and S1203 is repeated until there are no more start and end symbols that have not yet been acquired (S1207-No). If there are no start and end symbols that have not yet been acquired (S1207-No), component definition information 100 with the stored description is created (S1209), and the process ends.

[0060] After the processing by the component extraction unit 1001 is completed, the output unit 210 outputs the component definition information 100 created by the component extraction unit 1001 .

[0061] According to this embodiment, by specifying a part of the part definition information, it is possible to output only the necessary part definition information.

[0062] <Third embodiment> After developing a GUI by reusing the component definition information 100 output by the component definition information management system, a developer continues development in response to requests from users who operate the GUI to make the GUI more suited to business characteristics. At this time, the developer considers replacing the reused component definition information 100 with a different component definition information 100 to expedite development. However, when the developer reuses the component definition information 100, parameter setting work is required. For example, to change the character string displayed on a button from "Login" to "Sign in," the developer must change the setting of the parameter that defines the character string to be displayed. Performing this work every time the component definition information 100 is replaced is inefficient. Therefore, in this embodiment, the part definition information 100 obtained from the output of the part definition information management system is used to search for the part definition information 100, and when replacing it with different part definition information, the replaced part definition information 100 inherits the parameters of the part definition information 100 before the replacement, thereby avoiding the need to set the parameters again.

[0063] First, an example of the functional configuration of the part definition information management system 200(b) in this embodiment will be described with reference to Fig. 13. Fig. 13 is a diagram showing an example of the functional configuration of the part definition information management system 200(b) in the third embodiment. Compared to Fig. 10, which is a functional configuration diagram of the part definition information management system 200(a) in the second embodiment, it differs in that it includes an exchange input unit 1300 and an exchange storage unit 1301, but is otherwise the same.

[0064] In the second embodiment, the search unit 209 searches for the component definition information 100 based on input of business information, and extracts and outputs a portion of the component definition information 100 based on a part of the component definition information 100 specified by the specification unit 900. This embodiment differs in that input of replacement component definition information 100 is accepted, the input component definition information 100 is used to search for the component definition information 100, and the parameters of the component definition information 100 before replacement are inherited by the component definition information after replacement. Only this difference will be described below.

[0065] The replacement input unit 1300 accepts input of component definition information 100. The component definition information 100 input here is the component definition information 100 output by the component definition information management system. The search unit 209 uses the name of the component definition information 100 to enable searching of the component definition information 100 and the abstraction level table 500.

[0066] The replacement storage unit 1301 stores parameters held in the component definition information 100 input to the replacement input unit 1300. After the component extraction unit 1001 extracts components in the same manner as in the second embodiment, the parameters stored in the replacement storage unit 1301 are described in the component definition information 100 created by the component extraction unit 1001. Then, the output unit 210 outputs the component definition information 100 in which the parameters are described.

[0067] According to this embodiment, when the component definition information is replaced, the parameters held in the component definition information that has been output once can be inherited by the replaced component definition information, thereby avoiding the need to set the parameters again. Note that although the component definition information 100 created by the component extraction unit 1001 has been described as an example, the component definition information 100 with the parameters inherited can also be output in the same way in the first embodiment.

[0068] <Fourth embodiment> In the first embodiment, the analysis unit 205 calculates the commonality rate by calculating a numerical value representing the ratio of the number of component definition information 100 with a certain start and end symbol among the component definition information 100 associated with the same component use. In this embodiment, a method is considered that enables a developer who intends to reuse a component to more accurately select the component definition information 100 that he or she desires. For example, the component definition information 100 that a developer desires to reuse differs depending on whether the developer is focusing on the basic structure of the GUI, such as the type and function of the GUI, such as buttons and forms, or on the GUI decoration, such as layout and color. In this embodiment, a description that determines the GUI type, the character strings and images to be displayed, and the functions is defined as a description of GUI generation, representing the basic structure. Also, a description that determines the GUI shape, size, layout, color, and font is defined as a description of GUI style information, representing the GUI decoration. Here, the component definition information 100 can distinguish between a description of GUI generation and a description of GUI style information. For example, in the case of a button in the component definition information example 100(a) shown in Figure 1, setType, setView, and setEvent are descriptions of GUI generation, and shape, size, placement, color, and font are descriptions of GUI style information. In this embodiment, when calculating the commonality rate, a method is shown in which, among the descriptions surrounded by the acquired start and end symbols, descriptions of GUI generation and descriptions of GUI style information are distinguished and weighted to calculate the commonality rate.

[0069] First, an example of the functional configuration of the part definition information management system 200(c) in this embodiment will be described with reference to Fig. 14. Fig. 14 is a diagram showing an example of the functional configuration of the part definition information management system in the fourth embodiment. Compared to Fig. 2, which is a functional configuration diagram of the part definition information management system 200 in the first embodiment, the difference is that the method of calculating the commonality rate in the analysis unit 205 is different and that a weight setting unit 1400 is included, but the rest is the same.

[0070] In the first embodiment, the analysis unit 205 acquires the start and end symbols described in the component definition information 100, and calculates the commonality rate using a numerical value that represents the proportion of component definition information 100 with a certain start and end symbol among the component definition information 100 associated with the same component use. However, in this embodiment, the commonality rate is calculated by distinguishing between the GUI generation description and the GUI style information description among the descriptions surrounded by the acquired start and end symbols and weighting them. Only this difference will be explained below.

[0071] When calculating the commonality rate of start and end symbols, the analysis unit 205 simultaneously calculates the essential commonality rate of each start and end symbol, as in the first embodiment. In this embodiment, the essential commonality rate is calculated by comparing the character strings of the GUI generation description and the GUI style information description for descriptions enclosed by the same start and end symbols, and then multiplying each description commonality rate by a weight based on the weight set by the weighting unit and adding up the weights. In this embodiment, the description commonality rate is a numerical value representing the ratio of the number of start and end symbols that a certain description shares with descriptions enclosed by the same start and end symbols in multiple component definition information 100. When a description enclosed by certain start and end symbols in a certain component definition information 100 has S parameters, and these parameters are shared by T parameters with descriptions enclosed by the same start and end symbols, the description commonality rate is T / S*100.

[0072] When the analysis unit 205 calculates the essential commonality rate by comparing the description content enclosed by start and end symbols, the weighting setting unit 1400 assigns weights depending on whether the description is a GUI generation description or a GUI style information description. To do this, the weighting setting unit 1400 sets weight values ​​according to the operation of the developer who reuses the component via the input device 1705, which will be described later. As shown in the example of Fig. 15, the developer who reuses the component can set the weight of the GUI generation description to 90% and the weight of the GUI style information description to 10% by inputting numerical values ​​using the keyboard. For example, the screen of Fig. 16 can be displayed, and the weighting settings can be input into the input form.

[0073] Here, an example of calculating the essential commonality rate will be explained. Assume that a string comparison is performed on the description enclosed by the start and end symbols "ID password," and the result is that the string commonality rate (description commonality rate) of the GUI generation description is 100%, and the string commonality rate (description commonality rate) of the GUI style information description is 80%. Here, if the weight of the GUI generation description is set to 90% and the weight of the GUI style information is set to 10%, the essential commonality rate is 100% * 0.9 + 10% * 0.1 = 91%. Note that if the developer places importance on the string commonality rate (description commonality rate) of the GUI style information description, the weight of the GUI style information is set high.

[0074] The calculation results are output to the output unit 210 together with the outputs of the component definition information 100 and the abstraction level table 400 in the first embodiment, allowing the developer to check the essential commonality rate.

[0075] According to this embodiment, it is possible to determine the essential commonality of GUIs. Note that although the description has been given in comparison with the first embodiment, the processing according to this embodiment may be similarly executed in other embodiments.

[0076] <Hardware configuration> Next, an example of the hardware configuration of the component definition information management system will be described with reference to FIG. 17. As shown in FIG. 17, the component definition information management system (200, 200(a), 200(b), 200(c)) can be configured using a computer 1700, an input device 1705, and an output device 1706. The computer 1700 includes a processor (CPU 1702 in this example), a storage medium 1704, a ROM 1701, and a RAM 1703. The storage medium 1704 is an appropriate storage device such as a HDD. The storage medium stores data related to processing, for example, a component definition information group 1704-1, which is a group of component definition information 100. The storage medium 1704 also includes, as storage areas, the component definition information storage unit 204-1, the component use storage unit 204-2, the abstraction level storage unit 204-3, and the replacement storage unit 1301, all of which are described above. The ROM 1703 stores data related to processing. In this example, it stores various programs used to execute predetermined processing. The ROM 1703 stores the above-described component definition information input unit 201, component use input unit 202, registration unit 203, analysis unit 205, abstraction level classification unit 206, threshold setting unit 207, task information input unit 208, search unit 209, output unit 210, designation unit 1000, component extraction unit 1001, replacement input unit 1300, and weight setting unit 1400 as programs. The programs stored in the ROM 1703 include a commonality calculation program 1703-1 used to calculate a commonality, an abstraction level determination program 1703-2 used to determine the abstraction level, a search program 1703-3 used in search processing, and an extraction program 1703-4 used to extract the partial definition information 100. The RAM 1701 is configured as a main storage device, and the processor reads data into the RAM 1701 and executes predetermined processing.

[0077] Note that the hardware configuration is an example and may be changed as appropriate as long as the processing can be executed appropriately. For example, the processor may be any entity that executes the processing appropriately, and may be configured using, for example, other different types of semiconductor devices. As an example, the storage unit 204 may be configured to include a storage medium 1704 and a ROM 1703, but may be changed as appropriate as long as the appropriate processing can be performed. For example, the storage unit 204 may be configured with the storage medium 1704, and the programs and the like stored in the ROM 1703 may be stored in the storage medium 1704.

[0078] The input device 1705 is a component used by a user (developer, etc.) to input various types of data, and is appropriately configured using a mouse, keyboard, touch panel, etc. The output device 1706 is configured using an appropriate display, and the output device 1706 outputs, for example, the various types of data described above.

[0079] The present invention is not limited to the above-described embodiments and includes various modifications. For example, the above-described embodiments have been described in detail to clearly explain the present invention, and are not necessarily limited to those including all of the described configurations. Furthermore, it is possible to replace part of the configuration of one embodiment with the configuration of another embodiment, or to add the configuration of another embodiment to the configuration of one embodiment. Furthermore, it is possible to add, delete, or replace part of the configuration of each embodiment with another configuration. Furthermore, the order of each step in the processing of each embodiment may be changed as appropriate as long as the same results can be obtained. Furthermore, the above-described configurations, functions, processing units, processing means, etc. may be partially or entirely implemented in hardware, for example, by designing them as integrated circuits. The above-described configurations, functions, etc. may also be implemented in software, with a processor interpreting and executing a program that implements each function. Information such as the programs, tables, and files that implement each function can be stored in a storage unit such as a memory, a hard disk, or an SSD (Solid State Drive), or in an IC card, semiconductor recording medium, magnetic recording medium, or optical recording medium. [Explanation of symbols]

[0080] 100 Part definition information 101 GUI Examples 200 Part definition information management system 201 Part definition information input section 202 Parts use input section 203 Registration Department 204 Storage section 204-1 Part definition information storage unit 204-2 Parts use memory section 204-3 Abstraction level storage unit 205 Analysis Department 206 Abstraction level classification part 207 Threshold setting unit 208 Business Information Input Department 209 Search Department 210 Output section 300 Login Screen 301 Dashboard screen 302 Details screen 400 Parts Usage Table 500 Abstraction Table 1000 designated part 1001 Parts cutting section 1100 Search result display screen 1101 Preview display 1300 Replacement Input Unit 1301 Replacement storage unit 1400 Weighting setting section 1700 Computer 1701 RAM 1702 CPU 1703 ROM 1703-1 Common Rate Calculation Program 1703-2 Abstraction level judgment program 1703-3 Search Program 1703-4 Cutting program 1704 Storage medium 1704-1 Part definition information group 1705 Input Device 1706 Display device

Claims

1. A part definition information management system that selects part definition information, a part definition information input unit for acquiring the part definition information; a part use input unit for acquiring a part use; a registration unit that associates the part definition information with the part use; an analysis unit that analyzes a commonality of the content of the part definition information in units of the part usage; an abstraction level classification unit that assigns an abstraction level related to a threshold evaluation of the commonality rate to the part definition information based on the analysis result of the analysis unit; a threshold setting unit that sets a threshold that is a standard for the abstraction level classification unit to assign the abstraction level; a business information input unit that acquires business information related to a business when selecting part definition information; a search unit that searches for the component definition information associated with the component use corresponding to a character string included in the acquired business information, and acquires the component definition information that is found and the level of abstraction assigned thereto; an output unit that outputs the component definition information and the abstraction level acquired by the search unit, A parts definition information management system characterized by:

2. 2. The part definition information management system according to claim 1, a designation unit that designates a part of the part definition information to be output from the part definition information searched for by the search unit; a part extraction unit that extracts a part of the part definition information based on the specification by the specification unit, The output unit outputting the part extracted by the part extraction unit as part definition information; A parts definition information management system characterized by:

3. 2. The part definition information management system according to claim 1, an exchange input unit that receives as input the part definition information that is an output of the part definition information management system; The output unit outputting part definition information that inherits the parameters held in the part definition information received as input by the replacement input unit; A parts definition information management system characterized by:

4. 3. The part definition information management system according to claim 2, an exchange input unit that receives as input the part definition information that is an output of the part definition information management system; The output unit outputting part definition information that inherits the parameters held in the part definition information received as input by the replacement input unit; A parts definition information management system characterized by:

5. 2. The part definition information management system according to claim 1, a weighting setting unit that sets weighting according to the description of the part definition information; The analysis unit Calculating a commonality ratio based on the weighting. A parts definition information management system characterized by:

6. 3. The part definition information management system according to claim 2, a weighting setting unit that sets weighting according to the description of the part definition information; The analysis unit Calculating a commonality ratio based on the weighting. A parts definition information management system characterized by:

7. 4. The part definition information management system according to claim 3, a weighting setting unit that sets weighting according to the description of the part definition information; The analysis unit Calculating a commonality ratio based on the weighting. A parts definition information management system characterized by:

8. 5. The part definition information management system according to claim 4, a weighting setting unit that sets weighting according to the description of the part definition information; The analysis unit Calculating a commonality ratio based on the weighting. A parts definition information management system characterized by:

9. A part definition information management method for selecting part definition information, The part definition information management method includes: A method using a processor, a storage unit, an input device, and a display device, The processor: Acquire the part definition information; Obtain the part use, creating a part use table that links the part definition information with the part use, and storing the table in the storage unit; Analyzing a commonality rate of the content of the part definition information in units of the part usage; Based on the analysis results, an abstraction level table is created to be used for assigning abstraction levels relating to the threshold evaluation of the commonality rate to the component definition information; setting a threshold value as a standard for assigning the level of abstraction; acquiring business information relating to a business input by a user via the input device when selecting part definition information; searching the storage unit for the component definition information associated with the component use corresponding to the character string included in the acquired business information, and acquiring the component definition information found and the level of abstraction assigned thereto; outputting the acquired component definition information and the acquired level of abstraction to the display device; A part definition information management method comprising:

10. A program that causes a processor to execute the part definition information management method according to claim 9.

Images