The present invention relates to user interface software design systems for improving efficiency of design and development of user interface software used in devices equipped with software products, such as cellular phones, personal digital assistants, and car navigation systems.
In the field of devices equipped with software products, such as cellular phones, personal digital assistants, and car navigation systems, in recent years, shortening of the product life-cycle is significant due to advance in technology and dizzying pace of change in needs for such devices. In order to cope with such situations, improvement of efficiency of new product development, particularly design and development of software products, is required, so that there is an urgent need to accelerate the software product development by improving efficiency of development of user interface software that is important part of software products installed in the devices. User interface software design systems derive from such backgrounds in order to improve the efficiency of design and development of the user interface software.
In general, in software development, differential development is important in which, in order to improve efficiency of design and development, assets such as past design data are reused as much as possible, and only portions different from those of the past, such as new features, are newly designed. In the meanwhile, design data used for designing user interface software has been mostly made according to software designer's discretion of the time, so that most of design data has been inconvenient for reuse. For example, there have been cases in which substantially identical series of scenes are defined in a plurality of design data segments, or in which, by treating, as scene transitions in the same level, movement of user interfaces such as icons, occupying a portion of the screen, and switching of the entire screen, the scene transitions are planar and the number of scene transitions are large, so that the view of the entire design data gets worse. As described above, design concepts of individual designers are reflected without being unified in user interface software design data. As a result, the design data has not been sufficiently examined from the viewpoint of reusability, so that most of the design data has low reusability. In such circumstances, software designers create required design data by editing design data accumulated in the past each time when newly designing and developing user interface software, using a variety of editing means, being user interface design means, such as a state set editor, an event processing editor, a property editor, and a state display editor, and input the created data into a user interface software design system (see Patent document 1, for instance). Such a situation also results from the fact that design data creation is an extremely creative work, and highly depends on individual ability.
As described above, even when carrying out a differential development, regarding design data, the creation thereof often takes a lot of man-hours. Therefore, the purpose of differential developments in which the efficiency by reusing design data assets accumulated in the past is promoted has not been realized.
In the meanwhile, as a measure against a case in which past design data cannot be obtained in a form highly reusable for a new user interface software development, there is a method so-called reverse engineering. The method obtains design data by inputting and analyzing source codes of software in the past. There is a system therefor referred to as a reverse engineering support system (see Patent document 2, for example). An existing reverse engineering support system analyzes software structures using source codes as input data. Source codes of user interface software are often written in a form of event driven type that determines responses according to interaction with a user (more specifically, a system in which processing to be applied has been defined for each event, and activated according to the definition), so that it has been difficult to interpret the design information of the software from the source codes, and to obtain design data in an organized form so as to be easily reused.
Patent document 1: Japanese Patent Laid-Open No. 244848/2002 (claim 1, pages 3 and 4, and FIG. 1)
Patent document 2: Japanese Patent Laid-Open No. 101884/1997 (claim 1)
[Problem that the Invention is to Solve]
As described above, because design data accumulated from the past has been created by individual designers not based on unified design concepts, the reusability is low. In order to improve efficiency of differential developments of software, a means for improving the reusability of the accumulated design data has been desired.
[Means for Solving the Problem]
A user interface software design system of the present invention includes: an unorganized design data storage for storing as unorganized design data user-interface-software design data including events directed to a software product and information on software-product scene changes corresponding to the events; a rule storage for storing an organizing rule group, being a collection of organizing rules describing rules for converting the unorganized design data into reusable form; a rule processor for converting the unorganized design data into organized design data by reading out the unorganized design data stored in the unorganized design data storage and reading out the organizing rule group stored in the rule storage, and applying in sequence to the read-out unorganized design data each organizing rule included in the read-out organizing rule group, to analyze the unorganized design data; and an organized design data storage for storing the organized design data according to instruction by the rule processor.
[Effects of the Invention]
A user interface software design system relevant to the above-described invention converts unorganized design data that has been created not based on design concepts unified with each other during the design and development thereof, and that has been accumulated in an inconvenient form for reuse into highly reusable organized design data, whereby understanding of designer's intentions and user interface structures becomes easy, and efficiency of differential developments of user interface software and software products including the user interface software can be improved.
1: design data storage; 2: model analyzer; 3: input information generator; 4: software product; 5: model generator; 6: design data editor; 7: rule editor; 110: unorganized design data; 120: organized design data; 21: rule storage: 22: rule processor; 211, 212, 213, 214, and 216: organizing rules; 215: menu template.
Design data required for design and development of user interface software, which is a target of the invention relevant to the present application, is defined as scene change information referred to as scene sequences composed of a series of events to a software product (inputs by various operations, configurations, or the like) and display scenes that are switched by each event. The design data has a feature that the design data is more simplified compared with design data for general software. The invention relevant to the present application focuses on this point, and converts design data into an objectively and easily understandable form to improve reusability of the design data.
Next, the rule processor 22 applies in series each organizing rule included in the organizing rule group to the unorganized design data having been read. Each organizing rule includes a “condition” of application, and “applying process” describing the content of a process by the organizing rule. If the unorganized design data includes a portion that meets the “condition”, according to the “applying process”, conversions such as layering, unification, and division are performed on the unorganized design data (STEP 3). The processing in STEP 3 is performed on the entire unorganized design data. When the processing is completed, the rule processor 22 judges whether the processing in STEP 3 has been completed for all the organizing rules. If the rule processor judges that the processing has been completed (YES in STEP 4), the rule processor sends an instruction for storing in the organized design data storage 12 the design data after above-described conversion (STEP 5). The organized design data storage 12 stores the converted design data as organized design data according to the instruction by the rule processor 22 (STEP 6). If the rule processor 22 determines that there are organizing rules on which the processing in STEP 3 has not been performed, the rule processor 22 performs the processing in STEP 3 on the next organizing rule.
Next, a conversion procedure in STEP 3 in
By unifying unorganized data as above, when performing various processing such as enhancement, reduction, modification of functions for the scene sequence segments 1111 and 1121 for example, a software designer is not required to perform the processing for each of the scene sequence segments 1111 and 1121, but is required to perform necessary processing only for a definition portion of the scene EF illustrated as the organized design data 123, so that the processing can be largely simplified. The condition values n and m are predetermined values, and are determined with attention to their large effect on the software design.
By unifying unorganized data as above, when performing processing such as enhancement, reduction, modification of functions for the scene sequence segments 1141 and 1151 for example, a software designer is not required to perform the processing for each of the scene sequence segments 1141 and 1151, but is required to perform necessary processing only for the scene sequence segment 1241 in the organized design data. Moreover, in this example, because the branch structure is clearly expressed in the organized design data, the software designer can easily perform processing such as enhancement, reduction, modification of functions by branch increase and decrease processing, so that the processing can be largely simplified compared with performing similar processing for unorganized design data, and development efficiency can be improved. Furthermore, simplifying the processing improves reliability of completed software. The condition value n for the organizing rule 212 is a predetermined value, and is determined with attention to its large effect on the software design.
As described in the above two examples, using a rule storage 21 for storing a group of organizing rules, and the rule processor 22 for applying each organizing rule in the organizing rule group to the existing unorganized design data stored in the design data storage 1, the existing unorganized design data is processed by layering, unification, branching, division, or the like, to be converted into organized design data that is so organized that the design data structure is easy to understand. If unorganized design data is reused without modification, a software designer must examine, without seeing the software structure, the processing required for reuse for each design data to be reused when performing software function enhancement, reduction, or modification, or software structure modification, so that the design is accompanied by large difficulties. However, by performing the above-described organization, a software designer can easily understand other software designers' design intents, so that accumulated design data can be easily reused in performing software function enhancement, reduction, or modification, or software structure modification.
In addition, in the above description, two types of organizing rules have been explained as examples. However, the invention relevant to the present embodiment is not limited to these organizing rules, and the same effects can be achieved for other organizing rules. Moreover, the organizing rules have been expressed in table form, but are not limited to table form. It is only necessary that “conditions (including condition values)” and “applying process” that is performed when the conditions are satisfied are described therein. For example, even if the organizing rules are expressed in IF-THEN rules or other forms, effects similar to the above can be achieved. In addition, the relation between the unorganized design data storage 11 and the organized design data storage 12, and the design data storage 1 can be arbitrarily configured as having been described. In any of the configurations, effects similar to the above can be achieved.
Moreover, in the above description, the rule processor 22 applies all the organizing rules to the unorganized design data only one time. However, the rules can be applied a plurality of times. In a plurality of times of applications, the organized design data in the previous cycle is treated as unorganized design data. By repeatedly applying organizing rules as just described, the organization of the design data is promoted, and the design data can be converted into more reusable design data.
In an invention according to Embodiment 2, even if sufficient unorganized design data required for satisfying “conditions” of organizing rules is not accumulated, by newly generating and complementing unorganized design data, a state in which “conditions” of the organizing rule are satisfied is created to promote organization.
The procedures for converting unorganized design data into organized design data according to the present embodiment are illustrated in
If the “condition” is satisfied, the unorganized design data is converted into organized design data according to the content written in the “applying process” in the organizing rule 213 (using the “return event” in this example). The above-described processing is the same as described in Embodiment 1. However, there can be a case in which some unorganized design data is excluded from data to be organized because the condition is not satisfied, and the organization of the unorganized design data cannot proceed. In order to reduce such cases as much as possible, another organizing rule “return event identification 2” is placed after the organizing rule “return event identification 1”. If the “condition” of the “return event identification 2” is satisfied, design data is complemented according to “applying process” in the “return event identification 2”, and the complemented design data is included in the unorganized design data. Then the complemented unorganized design data is re-evaluated according to the “return event identification 1”.
The above-described processing will be explained according to
As described below, the complement is carried out by inputting an event into the software product 4 that is a basis for differential development. The rule processor 22 firstly determines the number k of data segments to be complemented (STEP 33). The value of k is a value written in the “applying process” in the “return event identification 2”, which should be arbitrarily determined in advance. Next, the rule processor 22 analyzes the organizing rule which is determined to require data complement, or more specifically analyzes the “applying process” in the “return event identification 1” in this example, to determine from what scene to start, and what kind of events are needed, when a series of scene sequence is complemented as design data (STEP 34). Regarding an initial scene to which an event is inputted at the beginning, depending on what type of design data is complemented, there are cases in which a scene sequence can start from an arbitrary scene, and cases in which a scene sequence must start from a specific scene. It is much the same for events. There are cases in which a specific event is designated, and there are cases in which an arbitrary event is applied to a specific scene.
In the case of the “return event identification 1”, the rule processor 22 fixes the event to be an event x, and the initial scene is arbitrarily designated. In addition, a known software product 4 is used as a basis for differential development in order to obtain design data to be complemented, so that an input event required for setting the above-described initial scene is known, and the rule processor 22 can recognize and set the event.
The rule processor 22 instructs the input information generator 3 to generate the event that has been set as described above (STEP 34 and STEP 35). The input information generator 3 firstly inputs to the software product 4 the event designated for displaying the initial scene (STEP 34), and changes the display screen to the designated initial scene. After that, the input information generator further inputs in series a designated event p required for obtaining a single scene sequence (in this example, an event x being the “return event”) to the software product 4 (STEP 35). In the software product 4, the processing for the event p is carried out, whereby the display screen is changed to the display scene p (STEP 36). The model generator 5 inputs, after transition to the initial scene, a series of events inputted to the software product 4 (only a single event x for the example of the return event), and the information on the resultant scene change in the software product 4 (STEP 37). The rule processor 22 judges whether processing for a series of events, required for complementing one scene sequence, has been completed (STEP 38). If the processing has not been completed, the rule processor repeats the processing in STEP 35 through STEP 37 until the processing for the series of events, required for complementing the one scene sequence, is completed.
If it has been determined that one scene sequence is obtained, the rule processor 22 then judges whether the generation of k scene sequences to be complemented, which is prescribed in the applying process in the organizing rule “return event identification 2”, has been completed (STEP 39). If it has been completed, the model generator 5 generates k scene sequences of design data from the series of inputted events and the corresponding scene change information (STEP 40). The data is referred to as model design data. The model generator 5 complements the unorganized design data with the model design data, and stores the model design data in the unorganized design data storage 11 as well (STEP 41). The rule processor 22 re-evaluates and organizes the unorganized design data after the complement according to the “condition” of the “return event identification 1” in the organizing rules 213 (STEP 42). As described above, k series of events and k kinds of display scene data corresponding to the events, or namely k scene sequences, are generated and supplied to the unorganized design data. However, it is not certain whether design data for satisfying the “condition” of the “return event identification 1” is complemented, and it can be a case in which the “condition” of the “return event identification 1” is not satisfied again. In such a case, how many times the “return event identification 1” and the “return event identification 2” are repeated can be clearly written in each application process.
The organizing rules 214 illustrated in
The unorganized design data in the example includes two scene sequences 118 and 119 being unorganized design data as illustrated in
As described in the above two examples, when the condition cannot be satisfied in terms of the number of data segments only by the unorganized design data stored in the design data storage 1, and the data cannot be well organized, the rule processor 22 sends an instruction for generating insufficient unorganized design data to the input information generator 3. The input information generator 3 having been received the instruction generates an event, and inputs the event into the software product 4. The model generator 5 generates model design data from the event inputted to the software product 4 and the scene change in the software product 4 caused by the input, complements the model design data as a portion of the unorganized design data, and stores the unorganized design data in the unorganized design data storage 11 as well. The rule processor 22 performs the same processing as the processing described in Embodiment 1 on the unorganized design data after the complement, and converts the unorganized design data into organized design data. Organized as described above, design data that has been unable to be organized due to insufficiency of design data can be organized, so that design data in more reusable form can be obtained. As described above, according to the present embodiment, the same effects as the effects of Embodiment 1 can be expected in wider range of cases.
According to the present embodiment, in addition to the above effects, even when a user interface software design system is used for the first time, certain level of effects can be expected. More specifically, even when unorganized design data 1 has not been accumulated in the unorganized design data storage 11, model design data can be easily generated via a software product 4 as a basis for differential development by the above-described process. The model design data, regarded as unorganized design data accumulated in the past, can be converted into organized design data. Therefore, from an early stage of using the user interface software design system, design and development can be performed more efficiently. Moreover, the present embodiment is not limited to the organizing rules described as examples here, but can be applied to other organizing rules in the same manner, and the same effects as above can be achieved.
In addition, in the above description, two types of organizing rules have been explained as examples. However, the invention relevant to the present embodiment is not limited to these organizing rules, and the same effects can be achieved for other organizing rules. Moreover, the organizing rules have been expressed in table form, but are not limited to table form. It is only necessary that “conditions (including condition values)” and “applying process” that is performed when the conditions are satisfied are described therein. For example, even if the organizing rules are expressed in IF-THEN rules or other forms, effects similar to the above can be achieved. In addition, the relation between the unorganized design data storage 11 and the organized design data storage 12, and the design data storage 1 can be arbitrarily configured as having been described. In any of the configurations, effects similar to the above can be achieved.
Moreover, in the same way as the explanation in Embodiment 1, the rule processor 22 can apply all the organizing rules to the unorganized design data a plurality of times. In a plurality of times of applications, the organized design data in the previous cycle is treated as unorganized design data. By repeatedly applying organizing rules as just described, the organization of the design data is promoted, and the design data can be converted into more reusable design data.
The preferential application of a rule template is necessary in a case, for example, in which it is known in advance that, in scene sequences within unorganized design data, specific scene sequence segments have specific forms, and are related to the precedent or subsequent scenes. In some cases, for such unorganized design data, design intent can be more appropriately expressed to apply a “rule template” in accordance with the scene sequence segments having the specific forms than to automatically apply organizing rules stored in the rule storage 21.
The procedure in STEP 22 will be described in detail below. In the menu template 215 illustrated in
Next, a variation of the present embodiment will be described. Here, the software designer, using the design data editor 6, designates in advance specific unorganized design data as data to which organizing rules are “not applicable”. The designated design data, or the scene sequence, is exempted from application of organizing rules. The processing according to the designation is often required in such a case in which design data that has been organized to a certain extent is organized again.
As illustrated in
In addition, this function can be also used when it is desired that the organized design data is organized again from another viewpoint. Specifically, the software designer designates using the design data editor 6 “exclusion of organization application (non-application)” with respect to design data that has been organized to a certain extent and that is not wanted to be organized any more. Then, the rule processor 22 instructs to store as unorganized design data in the unorganized design data storage the entire design data that has been organized to a certain extent including the design data having non-application designation, and applies the organizing rules again to the unorganized design data so as to perform organization.
A specific example is illustrated in
As described above, introduction of the design data editor 6 enables a software designer to perform not only analysis and conversion according to automatic application of organizing rules, but also organization of design data in accordance with individual design data situation in reflection of the designer's intent, so that more reusable design data can be configured. In addition, in the above-described example, a design data editor 6 is used as a means for designating the preferential application of rule templates, and a means for designating the exclusion of application of organizing rules. However, any means that can substantially perform above-described designation for design data may be used instead of an “editor”, and the same effects as in the present embodiment can be achieved. Moreover, although in the present embodiment, an example in which a design data editor 6 is added to a system illustrated in
Moreover, the invention relevant to the present embodiment is not limited to the exemplified organizing rules, and the same effects can be achieved when using other organizing rules. Moreover, the organizing rules have been expressed in table form, but are not limited to table form. It is only necessary that “conditions (including condition values)” and “applying process” that is performed when the conditions are satisfied are described therein. For example, even if the organizing rules are expressed in IF-THEN rules or other forms, effects similar to the above can be achieved. In addition, the relation between the unorganized design data storage 11 and the organized design data storage 12, and the design data storage 1 can be arbitrarily configured as having been described. In any of the configurations, effects similar to the above can be achieved.
Moreover, in the same way as the explanation in Embodiment 1, the rule processor 22 can apply all the organizing rules to the unorganized design data a plurality of times. In a plurality of times of applications, the organized design data in the previous cycle is treated as unorganized design data. By repeatedly applying organizing rules as just described, the organization of the design data is promoted, and the design data can be converted into more reusable design data.
Embodiment 4 is configured such that a rule editor 7 is added to any of the embodiments having been described. The rule editor 7 enables a software designer to perform operations such as addition, removal, and modification of organizing rules or templates stored in the rule storage 21, and to change the order of applying the rules as well. Providing such a means makes it possible to improve the organizing rule group or to make rule-applying processes appropriate, and as a result a software designer can organize design data more effectively. According to the above, more reusable design data that has been organized in a form in which design intent is easily understandable can be configured. In addition,
The present invention is used for design and development of user interface software that is part of software in the field of devices equipped with software products, such as cellular phones, personal digital assistants, and car navigation devices.
Number | Date | Country | Kind |
---|---|---|---|
2003-356608 | Oct 2003 | JP | national |
Filing Document | Filing Date | Country | Kind | 371c Date |
---|---|---|---|---|
PCT/JP04/15124 | 10/14/2004 | WO | 3/8/2007 |