JP5311379B2 - Design support system and design support method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a design support system which attains a screen transition design without any ambiguity. <P>SOLUTION: This design support system displays a design support screen for supporting the design of screen transition based on the definition information of one screen and transition information showing transition between the screens. The design definition information includes background attributes showing the background of the screen, and when an operation to newly generate a screen of a user is accepted, the number of screens to be generated, the background attributes of each screen to be generated, and state transition to the screens to be generated are determined, and the number of the screens to be generated and the background attributes of each screen to be generated are determined based on commands to be used for the generation of the screens, the number of screens selected as the origin of generation and the background attributes of the selected screens, and the state transition to the screens to be generated is determined based on the commands to be used for the generation of the screens and the number of screens selected as the origin of generation. <P>COPYRIGHT: (C)2010,JPO&amp;INPIT

Description

  The present invention relates to a system that supports screen design of a car navigation system, a mobile phone, and the like.

  In the current car navigation system, an enormous number of screens are displayed as functions are advanced. In order to design the transition of these screens, a screen flow diagram as shown in FIG. 1 is used. As a method for describing a screen flow diagram using a computer, there are a method using a general graphic drawing program and a method using an editor dedicated to screen transition design.

  In general, when an editor dedicated to screen transition design is used, screen transition design can be easily performed at the following two points as compared with the case of using a graphic drawing program. The first is to have a function dedicated to screen transition design, and the second is to adopt a data structure suitable for expressing the screen transition.

  As a function dedicated to the screen transition design, as described in Patent Document 1, a window for displaying the selected screen in an enlarged manner is provided separately from the window representing the state transition, and an element (button) that triggers the state transition Etc.) is dragged and dropped onto a screen arranged in a window representing a state transition, and a method for creating a screen transition triggered by the element is known.

As a data structure expressing a general state transition including a screen transition, State Chart XML as described in Non-Patent Document 1 is known. In addition, as described in Patent Document 2, by assigning an attribute to screen transition, whether it is a normal transition or a transition for displaying a popup subordinate to the parent screen, etc. Methods are also known that allow specialized design.
JP 2007-133815 A Japanese Patent Laid-Open No. 11-249876 W3C Working Draft, “State Chart XML (SCXML): State Machine Notation for Control Abstraction”, [online], February 21, 2007, World Wide Web Consotium, Internet <URL: http://www.w3.org/ TR / scxml / ＞

  The problems of the prior art will be described using the screen flow diagrams of FIGS. 1A to 1C. As shown in FIG. 1A, a screen in which a pop-up screen changes with the same background screen is designed using a screen flow diagram. However, in the method of expressing the screen flow diagram shown in FIG. 1A, it cannot be expressed whether the background screen is accidentally the same or needs to be the same.

  In addition, as shown in FIG. 1B, it can be seen that the same pop-up is displayed regardless of which of the two background screens is changed. However, since the background screen of the transition destination is blank, it cannot be distinguished whether the background screen uses the background of the transition source or whether the background screen is painted white.

  In addition, in the case shown in FIG. 1C, the background image of the transition destination is specified, but the transition from the menu screen is created first, which means that it always makes the menu screen the background regardless of which screen the transition is made from. Then, since the transition from the map screen was created later, it cannot be distinguished whether the menu screen is drawn in the background.

  Such ambiguity results in a program created based on the screen transition design being different from the intention of the screen transition designer. Further, when the screen transition designer tries to design while eliminating ambiguity, it takes time to write a large number of comments or to design while considering an expression method without ambiguity.

  An object of the present invention is to provide a screen transition support system that can easily design a screen flow while eliminating such ambiguity.

A typical example of the present invention is as follows. That is, the design support system displays a design support screen for supporting the design of screen transition based on the definition information of at least one screen and the transition information indicating the transition between the at least one screen. Then, the design support system manages design definition information including a background attribute indicating the background of the screen, and receives a user's operation to newly generate the screen, the number of screens to be generated is generated. The background attribute of each screen and the state transition to the generated screen are determined. The number of the generated screens and the background attribute of each generated screen are commands used for generating the screens, The state transition to the generated screen is determined by the number of screens selected as the generation source and the background attribute of the selected screen, and the command used to generate the screen and the live A design support system characterized in that it is determined by the selected number of screens as the original.

  According to the present invention, an unambiguous screen transition design can be realized, and the number of screen design steps can be reduced.

  Next, embodiments of the present invention will be described with reference to the drawings.

<Embodiment 1>
FIG. 2 is a block diagram showing the system configuration of the screen transition design support system 200 according to the first embodiment of this invention.

  In the screen transition design support system 200 of the first embodiment, one or more personal computers (PCs) 213A, 213B,... And a database (DB) 214 are connected by a network 209.

  The DB 214 includes a storage device for recording screen transition design information, and is realized by executing a database management system (DBMS) on any PC. Accordingly, when the screen transition design support system 200 according to the present embodiment includes one PC 213, a stand-alone configuration in which the DBMS is executed by the one PC may be used. On the other hand, the DB 214 may be shared by a plurality of PCs 213.

  The PC 213A is a computer that executes a screen transition design support program, and includes a CPU 201, a RAM 202, an HDD 203, a ROM 204, a DVD drive 205, an I / O interface 206, and a network interface 207. These components are connected by a bus 208. ing.

  Input / output devices such as a mouse 210, a keyboard 211, and a display 212 are connected to the PC 213A via an I / O interface 206. These input / output devices provide a human interface to a user who uses the screen transition design support program. The PC 213A is connected to another PC 213B and the DB 214 via the network interface 207.

  Although the configuration of the PC 213A has been described, the other PC 213B has the same configuration.

  The screen design support program is distributed by a storage medium such as a CD-ROM or a DVD-ROM. The screen design support program is read by the installer using the DVD drive 205 and installed in the HDD 203. The installed program is loaded from the HDD 203 to the RAM 202 and executed by the CPU 201.

  FIG. 3 is an explanatory diagram illustrating an example of a screen design support screen displayed on the display 212 in the operation state of the screen design support program according to the first embodiment of this invention.

  In the screen design support screen of the present embodiment, rectangles representing six screens (A to F) are displayed, and the respective screens are connected by arrows representing screen transitions. Further, the value of the background attribute of each screen (A to F) is displayed on this screen design support screen. Further, in the rectangle representing each screen (A to F), a screen image constituted by a background and screen parts other than the background is displayed. The screen image generation algorithm will be described later.

  4A to 4F are explanatory diagrams illustrating an example of data expressing the design information of each screen corresponding to the screen transition design illustrated in FIG. 3 in the XML format.

  Each screen is defined by a <scene> tag. Below the <scene> tag, a button represented by a <button> tag, a character string label represented by a <label> tag, a GUI component such as a map displayed by a <map> tag, and <form> A form represented by a tag (a form is a GUI part for grouping several GUI parts) can be described. Since <label>, <button>, and <form> can be described under the <form> tag, it is possible to define a screen design having a hierarchical structure. Although only four GUI parts are illustrated here, a form for automatically laying out GUI parts such as a scroll bar and subordinate GUI parts may be added.

  The <scene> tag has a background attribute and designates a GUI component corresponding to the background in the screen design. As shown in FIG. 4A, on screen A, a form with id = “form1” is designated as the background. Since the screen A has no GUI parts other than this form, the screen A is composed only of the background. When the background GUI component is defined in the screen as described above, the background attribute is “unique”.

  On the other hand, as shown in FIG. 4E, in the screen E, the background attribute is omitted. In this case, too, the background attribute is assumed to be “unique”, and the child tag of the first <scene> tag is displayed as the background attribute. It may be a GUI part to be represented.

  On the other hand, as shown in FIG. 4B, by describing the background attribute “#A” on the screen B, it is specified that the background of the screen A is used without defining the background design independently. In this case, the background attribute is “reference”.

  Further, <label> defined on the screen B represents a GUI component to be displayed over the background of the screen A. On the screen F, the background attribute is set to “##”. This specifies that a specific background screen is not specified, and that the same background design as the previous screen is used according to the screen transition. In this case, the background attribute is “transition source”.

  FIG. 5 is an explanatory diagram illustrating an example of data in which the screen transition information corresponding to the screen transition design illustrated in FIG. 3 is expressed in the XML format.

  The screen transition information is a definition of in which case the state transitions to which state, and can be described in SCXML (State Chart XML) standardized by W3C. However, the screen transition information of the present embodiment is not sufficient for the information on which screen to transition from which screen, and each screen is arranged at which position and in what size on the design support screen (FIG. 3). And layout information such as where the arrow indicating the transition is bent. Such layout information may be described separately from SCXML.

Further, as shown in FIG. 5, a tag expressing layout information may be added to SCXML. For example, the display position and size of screen A are
<view x = "50" y = "30" width = "80" height = "40"/>
Is defined as follows. Furthermore, the bent part of the arrow indicating the transition from the screen A to the screen F is indicated by a <bendpoint> tag.
<bendpoint x = "100" y = "140"/>
Is defined as follows.

  FIG. 6 is a flowchart showing an algorithm for generating a design support screen of the format shown in FIG. 3 from the screen transition design information described in FIGS. 4 and 5.

  First, the screen transition definition XML illustrated in FIG. 5 is read (S600). The process of S601 is performed for all states represented by <state> tags defined in the screen transition definition.

  Next, details of the processing of S601 will be described. First, x, y, width, and height attributes representing the position and size of the rectangle are read from the <view> tag that is a child tag of <state>, and the rectangle is drawn according to this information (S602).

  Next, the design definition XML having the <scene> tag having the same id attribute as the id attribute of the <state> tag is searched from the RAM 202 or the DB 214, and the searched design definition XML is read (S603). When read from the DB 214, the read design definition XML may be held in the RAM 202 as a cache for speeding up the processing.

  Next, according to the background attribute of the <scene> tag of the read design definition XML, a character string of “unique”, “transition source”, or “reference” is drawn in the vicinity of the rectangle. If the screen attribute is “reference”, the screen ID of the reference destination is also drawn (S604).

  In S605, the process is distributed according to the value of the background attribute. First, when the value of the background attribute is “unique”, the GUI component specified by the background attribute is drawn in the rectangle as a background design (S606), and the process proceeds to S608.

  On the other hand, if it is determined in step S605 that the background attribute is “reference”, the reference <scene> is read (S607), and the GUI component specified by the background attribute of the <scene> is used as the background design. Drawing in the rectangle (S606). At this time, if the background attribute of the reference destination <scene> is a reference or transition source, an error may be generated, and the value of the reference destination background attribute may be recursively processed from step S605. Thus, for example, when the background attribute of the screen C refers to the screen B, the background attribute of the screen B refers to the screen A, and the screen A has its own background design defined, the screen C The background design of the screen A can be used as the background design. Thereafter, the process proceeds to S608.

  Furthermore, when it is determined in step S605 that the background attribute is “transition source”, the background design is not displayed, and thus the process proceeds to step S608. Even when the background attribute is “reference” or unique, after the background design is drawn in step S606, the process proceeds to S608.

  In step S608, a GUI component other than the background design defined in <scene> is drawn.

  Finally, in step S609, a line representing screen transition is drawn for each <transition> element defined in each <state>. At this time, if <bendpoint> is not designated, a straight line directly connecting the screens is drawn. On the other hand, when <bendpoint> is designated, a line that passes through the coordinates designated by <bendpoint> (a broken line that bends at the designated coordinates) is drawn.

  As described above, according to the first embodiment of the present invention, an unambiguous screen design support screen can be generated from the screen transition design information expressed in the XML format.

<Embodiment 2>
Similarly to the first embodiment, the screen transition design support system according to the second embodiment of the present invention is also realized by a program executed on a system including the computer shown in FIG. The second embodiment is different from the first embodiment described above in that the background design of the screen whose background attribute is the transition source is determined.

  FIG. 7 is a flowchart showing an algorithm for generating a screen design support screen from the screen transition design data illustrated in FIGS. 4 and 5 in the second embodiment of the present invention.

  Steps S600 to S609 are the same as those in the first embodiment described above, but the processing when the background attribute is determined to be “transition source” in S605 is different (S700).

  In step S700, it is determined whether or not all the screens transitioning to <state> display the same background design.

  First, it is assumed that all the background designs are the same, and the value of the reference screen variable that holds the ID of the screen that uniquely defines the background design is assumed to be “null” (S701). First, <state> (transition source) having a state transition to the current <state> is searched from the screen transition definition, and the processing of step S702 is executed for each searched transition source. Step S702 is a set of a plurality of steps (S703 to S706) that are recursively called.

  In S703, the process is divided according to the value of the background attribute of the transition source. If the background attribute of the transition source is “transition source”, the screen that is actually displayed is determined by the transition source of the screen on which this processing is performed, and therefore step S702 is recursively called (S705).

  On the other hand, when the background attribute is “unique” or “reference”, the identifier of the screen having the background design to be displayed can be acquired. If this identifier and the identifier held in the reference screen are different, there is a possibility that a plurality of screens may be displayed, so the process goes through S700 and moves to S608 (S704).

  If the reference screen variable is null (no screen identifier is input to the reference screen variable), even if S702 is recursively called, all recursive calls are exited and the process returns to S608. Move. As a result, when there are a plurality of types of screens whose background attributes may be displayed on the transition source screen, the background design can not be displayed.

  On the other hand, if the reference screen variable is null in step S704, or if the identifier of the screen held by the reference screen variable is the same as the identifier of the screen specified by the background attribute, the reference screen variable The identifier of the screen is input (S706).

  That is, the step S700 ends normally when the determination in S704 has never been “Yes”. In this case, since the backgrounds of the screens that are the transition sources of this screen are all the same, the reference screen variable holds the identifier of the screen that defines the only background design to be displayed in this <state>. Thereafter, the process proceeds to step S606.

  In step S606, the background design is displayed according to the identifier of the screen held in the reference screen variable. However, if the reference screen variable is null, the user may be warned. This is because if the reference screen variable is null and the process exits from S700, it is considered a design error.

  As shown in FIGS. 8A and 8B, when the background design displayed on the screen whose background attribute is the transition source is uniquely determined by the above-described processing, the determined background design is displayed. On the other hand, as shown in FIG. 8C, when the background design is not uniquely determined, the background design is not displayed. Thereby, it is possible to determine whether or not the background of the screen whose background attribute is the transition source is uniquely determined, and it is possible to accurately provide the user with the information of the transition source.

<Embodiment 3>
Similarly to the first embodiment, the screen transition design support system according to the third embodiment of the present invention is also realized by a program executed on a system configured by the computer shown in FIG. The third embodiment differs from the second embodiment described above in the process of determining the background design of the screen whose background attribute is the transition source.

  FIG. 9 is a flowchart illustrating an algorithm for generating a screen design support screen from the screen transition design data illustrated in FIGS. 4 and 5.

  Steps S600 to S609 are the same as those in the first embodiment described above, but the processing when the background attribute is determined to be “transition source” in step S605 is different (S900).

  In step S900, the background design type of the screen that transitions to <state> is counted.

  First, the list of screen identifiers defining the background design is initialized (S901), and the process of step S902 is executed. Step S902 is a set of a plurality of steps (S903 to S907) that are recursively called.

  In step S902, <state> (transition source) having a state transition to the current <state> is searched from the screen transition definition, and the processing in steps S903 to S905 included in S902 is performed for each <state>. Execute.

  In step S903, the process is distributed according to the background attribute value of the transition source. When the background attribute of the transition source is “transition source”, the screen that is actually displayed is determined by the transition source of the screen on which this processing is performed, and thus step S902 is recursively called (S905).

  On the other hand, if the background attribute is “unique” or “reference”, the identifier of the screen having the background design to be displayed can be acquired, and the acquired identifier is added to the reference screen list (S904).

  Through the processing described above, a list of identifiers of screens defining background designs that may be displayed with the <state> is created in the reference screen list. In step S906, processing is distributed according to the number of lists.

  First, if there is only one list, there is only one type of transition source screen, so the process moves to step S606 to display the background design. On the other hand, if the list is 0, there is no background design to be displayed, and the process moves to S608. However, since this is considered a design error, a warning should be presented. Further, if there are two or more lists, there is a possibility that a plurality of background designs may be displayed in that <state>, so the process moves to step S907 and an icon indicating that there are a plurality of background designs is displayed.

  When the background design displayed on the screen whose background attribute is the transition source is uniquely determined by the above-described processing, as illustrated in FIGS. 10A and 10B, the determined background design is displayed, and the background design is displayed. If it is not determined uniquely, the background design is not displayed, and this screen displays that there may be multiple backgrounds. For example, the icon 1000 in FIG. 10B indicates to the user that there are two types of background designs on this screen.

  When the user clicks this icon, a list of screen designs corresponding to screen identifiers held in the reference screen list created in FIG. 9 may be displayed.

  As described above, in the third embodiment of the present invention, it is possible to grasp a background design that may be displayed on a screen whose background attribute is a transition source.

<Embodiment 4>
Similarly to the first embodiment, the screen transition design support system according to the fourth embodiment of the present invention is also realized by a program executed on a system including the computer shown in FIG. In the screen design support system for displaying the screen design support screen as shown in the first to third embodiments of the present invention, the fourth embodiment of the present invention has a screen transition definition as shown in FIG. Provide an efficient way to create.

  In the fourth embodiment, as an operation for adding a new screen, one or a plurality of existing screens is used instead of a method of arranging a new screen independent of other screens on the screen transition design support screen. A method of generating a new screen by selecting and then executing a specific command is provided.

  FIG. 11 is a flowchart showing processing started by executing a specific command after the user selects one or a plurality of existing screens on the screen transition design support screen. 12 and 13 are explanatory diagrams of tables referred to in the process shown in FIG.

  First, the number of screens newly generated by a user operation and the background attributes of those newly generated screens are determined (S1100). To determine this, reference is made to the table shown in FIG. The row to be referred to in the table is determined by the command, the number of selected screens, and the value of the background attribute of the selected screen (copy source) at the start of the processing shown in FIG. The number of newly generated screens and the background attribute of the newly generated screen are determined by the determined line. When "-" is described in the table, it indicates that an arbitrary value is acceptable.

  The paste command is a command representing paste in a general copy and paste operation. The number of selections in this case is the number of screens selected when the copy operation was performed immediately before. Specifically, when one screen is selected, only one screen is generated by the paste operation. On the other hand, when a plurality of screens are selected and copied and then pasted, a copy of the selected plurality of screens is generated.

  Applying the principle of copy and paste that can be intuitively understood by the operator, the number of screens newly generated by the paste operation is selected regardless of the selected screen and the background attribute of the selected screen. It is good to be the number of screens. In general copy and paste, the attribute value of the object is copied as it is, and therefore the background attribute value of the newly generated screen may be used as it is. The table shown in FIG. 12 is configured in this way.

  In this embodiment, when a paste operation is performed while holding down the Shift key, or when dragging and dropping (D & D) while holding down the Shift key while the screen is selected, a new state transitions from the selection screen. The screen is generated.

  FIG. 14A to FIG. 14C are explanatory diagrams illustrating an operation of dragging and dropping while pressing the Shift key in a state where a screen is selected. In addition, when the paste operation is performed while the Shift key is pressed, a new screen whose state transitions from the screen that was selected when the copy operation was performed most recently is generated.

  In the case of these operations, as shown in the table (shown in FIG. 12), there is always one newly generated screen. On the other hand, the background attribute of a newly generated screen is determined according to the number of selected screens and the value of the background attribute of those screens. For example, in the case shown in FIGS. 14A to 14C, a plurality of screens having different background designs are selected (FIG. 14A), and the selected screens are dragged and dropped while the Shift key is pressed (FIG. 14B). Then, a screen whose state transitions from the selected screen is generated (FIG. 14C).

  The operations illustrated in FIGS. 14A to 14C correspond to the row (1201) of “Shift + Paste / D & D”, “Plural”, “Unique only / including transition source” in the table. In this case, the background design of the newly generated screen is optimally designed to change according to the screen of the transition source, so the background attribute is desirably the transition source.

  On the other hand, the lower row (1202) corresponds to the case where all the background attributes of the plurality of selection screens are references. In this case, if all the screens referred to are the same, the screens transitioning from those screens may be referred to as the background design. On the other hand, when references to different screens are mixed, the design in which the background design follows the transition source is optimal. From this consideration, in the case of this operation, the background attribute of a newly generated screen is determined to be a reference if the reference destinations are all the same, and to be a transition source if the reference destinations are different.

  Similarly, in other cases, the optimum number of generated screens and background attributes of the generated screens are determined according to “command”, “number of selected screens”, and “background attributes of selected screens”.

  Next, in step S1101, state transition between the selected screen and the newly generated screen is determined. For this purpose, a specific line is determined from the table shown in FIG. 13 according to “command” and “number of selected screens”, and logic for generating a state transition described in the determined line is executed.

  In a normal paste operation (1301, 1302), no state transition is generated between the selected screen and a newly generated screen. However, when a paste operation is performed after a plurality of screens are selected and copied, the state transition between the selected screens is copied as it is.

  In the case of Shift + Paste and Shift + D & D (1303), a state transition from one or a plurality of selected screens to one newly generated screen is generated. As a result, a state transition connecting the selection screen and the newly generated screen is generated (FIG. 14C).

  In step S1102, the screen newly generated in step S1100 is set as a selection screen. As a result, when Shift + paste is continuously performed, new screens with state transitions from the screen last generated by the paste can be generated one after another as shown in FIG.

  Next, in S1103, <state> and <new> generated in steps S1100 and S1101 by using the algorithms (FIGS. 6, 7, and 9) of the first to third embodiments of the present invention. The user's operation result is fed back by drawing the screen transition support screen based on the information of “transition>”. 15A to 15D show a case where the screen transition support screen is redrawn by the algorithm according to the third embodiment of the present invention.

  First, generation of screens illustrated in FIGS. 15A to 15C will be described.

  As shown in FIG. 15A, when a plurality of screens 1501 and 1502 are selected and a copy operation is performed, the selected plurality of screens become the transition source. The background attributes of the selected screens 1501 and 1502 are “unique”, and the background of each screen is different. Accordingly, since there are a plurality of transition source background screens, a new screen 1503 having a background attribute of “transition source” is generated in the first paste operation. A newly generated screen 1503 displays icons indicating the possibility of a plurality of background designs (icons indicating the number of background designs).

  As shown in FIG. 15A, after the first paste operation, a newly generated screen 1503 is in a selected state. Therefore, when the second pasting operation is continued, a screen 1504 transitioning from the screen 1503 is newly generated as shown in FIG. 15B. Since the background attribute of the screen 1503 that is the transition source of the screen 1504 is “transition source”, the background attribute of the newly generated screen 1504 is “transition source”. In addition, a newly generated screen 1504 displays icons indicating the possibility of a plurality of background designs (icons indicating the number of background designs).

  As shown in FIG. 15B, after the second paste operation, the newly generated screen 1504 is in a selected state. Therefore, when the third paste operation is subsequently performed, a screen 1505 that transitions from the screen 1504 is newly generated as illustrated in FIG. 15C. Since the background attribute of the screen 1504 that is the transition source of the screen 1505 is “transition source”, the background attribute of the newly generated screen 1505 is “transition source”. Further, a newly generated screen 1505 displays icons indicating the possibility of a plurality of background designs (icons indicating the number of background designs).

  Next, generation of the screen illustrated in FIG. 15D will be described. When one screen 1511 is selected and a copy operation is performed, the selected one screen becomes a transition source. The background attribute of the selected screen 1511 is “unique”. Therefore, in the first paste operation, a new screen 1512 with the background attribute “reference” is generated. A newly generated screen 1512 displays the same background as the background of the reference source screen 1511.

  After the first paste operation, the newly generated screen 1512 is in a selected state. Therefore, when the second paste operation is subsequently performed, a screen 1513 transitioning from the screen 1512 is newly generated. Since the background attribute of the screen 1512 that is the transition source of the screen 1513 is “reference”, the background attribute of the newly generated screen 1513 is “reference”. The newly generated screen 1513 displays the same background as that of the reference source screen 1512.

  Furthermore, since the newly generated screen 1513 is selected after the second paste operation, a screen 1514 that transitions from the screen 1513 is newly generated when the third paste operation is continued. Since the background attribute of the screen 1513 that is the transition source of the screen 1514 is “transition source”, the background attribute of the newly generated screen 1514 is “transition source”. The newly generated screen 1514 displays the same background as that of the reference source screen 1513.

  In order to draw the screen transition support screen, it is also necessary to generate a <view> tag. For example, when the minimum rectangular area including the selection screen is represented by (X, Y, W, H), and the relative coordinates of each selection screen within the rectangular area are represented by (Xn, Yn), in the case of paste Sets (X + W + constant 1, Y, W, H) as an area for drawing a newly generated screen. Then, the x attribute and the y attribute of <view> can be determined so that the relative coordinates of each newly generated screen in the area are equal to (Xn, Yn).

  In the case of Shift + Paste / D & D, the <view> x attribute can be X + W + constant 1 and the y attribute can be Y-constant 2/2. Constant 1 represents a default arrangement distance between screens, and constant 2 represents a default height of the screen. An appropriate default value may be used for the width / height attribute of <view>. Of course, there are many existing methods for such automatic placement, and any of these methods may be used.

  As described above, in the fourth embodiment of the present invention, it is possible to quickly generate a screen having an optimal background attribute value and a state transition between the screens by an intuitive operation.

  In the fourth embodiment, the table shown in FIGS. 12 and 13 is used to sort the process according to the command, the number of selected screens, and the background attribute of the selected screen, and a newly generated screen is displayed. decided. However, a newly generated screen may be determined by processing including a plurality of branches without using a table.

  The present invention can be applied to a car navigation system having a large number of HMI screens and a tool for designing screen design specifications of a mobile phone or the like.

It is a figure showing the problem of a prior art. It is a figure showing the problem of a prior art. It is a figure showing the problem of a prior art. It is a block diagram showing the system configuration | structure of the screen transition design support system of the 1st Embodiment of this invention. It is explanatory drawing which shows an example of the screen design assistance screen of the 1st Embodiment of this invention. It is explanatory drawing which shows an example of the data which expressed the design information of each screen of the 1st Embodiment of this invention in the XML format. It is explanatory drawing which shows an example of the data which expressed the design information of each screen of the 1st Embodiment of this invention in the XML format. It is explanatory drawing which shows an example of the data which expressed the design information of each screen of the 1st Embodiment of this invention in the XML format. It is explanatory drawing which shows an example of the data which expressed the design information of each screen of the 1st Embodiment of this invention in the XML format. It is explanatory drawing which shows an example of the data which expressed the design information of each screen of the 1st Embodiment of this invention in the XML format. It is explanatory drawing which shows an example of the data which expressed the design information of each screen of the 1st Embodiment of this invention in the XML format. It is explanatory drawing which shows an example of the data which expressed the screen transition information corresponding to the screen transition design of the 1st Embodiment of this invention in the XML format. It is a flowchart which shows the algorithm which produces | generates a design assistance screen from the screen transition design information of the 1st Embodiment of this invention. It is a flowchart which shows the algorithm which produces | generates a design assistance screen from the screen transition design information of the 2nd Embodiment of this invention. It is explanatory drawing which shows the example of a display of the produced | generated screen of the 2nd Embodiment of this invention. It is explanatory drawing which shows the example of a display of the produced | generated screen of the 2nd Embodiment of this invention. It is explanatory drawing which shows the example of a display of the produced | generated screen of the 2nd Embodiment of this invention. It is a flowchart which shows the algorithm which produces | generates a design assistance screen from the screen transition design information of the 3rd Embodiment of this invention. The figure showing the example of a display of the screen design assistance screen of the 3rd Embodiment of this invention The figure showing the example of a display of the screen design assistance screen of the 3rd Embodiment of this invention It is a flowchart which shows the process started when the user of the 4th Embodiment of this invention selects a 1 or several existing screen on a screen transition design assistance screen, and performs a specific command. It is explanatory drawing of the table referred by the process shown in FIG. 11 of the 4th Embodiment of this invention. It is explanatory drawing of the table referred by the process shown in FIG. 11 of the 4th Embodiment of this invention. It is explanatory drawing which shows operation which drags and drops, pressing the Shift key in the state which selected the screen of the 4th Embodiment of this invention. It is explanatory drawing which shows operation which drags and drops, pressing the Shift key in the state which selected the screen of the 4th Embodiment of this invention. It is explanatory drawing which shows operation which drags and drops, pressing the Shift key in the state which selected the screen of the 4th Embodiment of this invention. It is a figure which shows an example of the result of the continuous operation of the 4th Embodiment of this invention. It is a figure which shows an example of the result of the continuous operation of the 4th Embodiment of this invention. It is a figure which shows an example of the result of the continuous operation of the 4th Embodiment of this invention. It is a figure which shows an example of the result of the continuous operation of the 4th Embodiment of this invention.

Explanation of symbols

200: Screen design support system 201: CPU
202 ... RAM
203 ... HDD
204 ... ROM
205 ... DVD drive 206 ... I / O interface 207 ... network interface 208 ... bus 209 ... LAN
210 ... Mouse 211 ... Keyboard 212 ... Display 213 ... PC
214 ... DB
1000 ... Icon representing the possibility of multiple background designs

Claims (10)

A design support system for displaying a design support screen for supporting design of screen transition based on definition information of at least one screen and transition information indicating transition between the at least one screen,
The design support system manages design definition information including a background attribute indicating the background of the screen ,
When an operation for newly generating the screen of the user is accepted, the number of generated screens, the background attribute of each generated screen, and the state transition to the generated screen are determined,
The number of generated screens and the background attribute of each generated screen are determined by the command used to generate the screen, the number of screens selected as the generation source, and the background attribute of the selected screen. And
The state transition to the generated screen is determined by a command used for generating the screen and the number of screens selected as a generation source. The background attribute is either “unique” uniquely defined on the screen, “reference” according to the background attribute of the referencing screen, or “transition source” according to the background attribute of the original screen that transitions to the screen. ,
The design support system according to claim 1, wherein a background of each screen displayed on the design support screen is determined by the background attribute. When a predetermined command is executed and one screen is selected as the generation source,
When the attribute of the screen selected as the generation source is “unique” or “reference”, the background attribute of the generated screen is determined as “reference”,
The design support system according to claim 2, wherein when the attribute of the screen selected as the generation source is “transition source”, the background attribute of the generated screen is determined as “transition source”. When a predetermined command is executed and a plurality of screens are selected as the generation source,
When the attribute of the plurality of screens selected as the generation source is only “unique”, the background attribute of the generated screen is determined as “transition source”,
When the attributes of the plurality of screens selected as the generation source include “transition source”, the background attribute of the generated screen is determined as “transition source”,
When the attribute of the plurality of screens selected as the generation source is only “reference” and the reference destinations of all the selected screens are the same, the background attribute of the generated screen is determined as “reference”. ,
When the attribute of the plurality of screens selected as the generation source is only “reference” and the part of the reference destination of the selected screen is different, the background attribute of the generated screen is determined as “transition source”. The design support system according to claim 2. When a given command is executed,
When one screen is selected as the generation source, a state transition between newly generated screens is not generated,
When a plurality of screens are selected as the generation source, the same state transition as the state transition between the plurality of screens selected as the generation source is generated as a state transition between newly generated screens. The design support system according to claim 1, wherein:   The design support system according to claim 1, wherein when the new screen is generated, the newly generated screen is in a selected state. When the background attribute is “unique”, the background of this screen is drawn based on the definition information of this screen,
When the background attribute is “reference”, the background of this screen is drawn based on the definition information of the reference screen of this screen,
The design support system according to claim 2, wherein when the background attribute is “transition source”, the background of the screen is not drawn. When the background attribute is “unique”, the background of this screen is drawn based on the definition information of this screen,
When the background attribute is “reference”, the background of this screen is drawn based on the definition information of the reference screen of this screen,
When it is determined that the background attribute is “transition source” and the backgrounds of all screens that transition to this screen are the same, the background of the transition source screen is drawn on the background of this screen. The design support system according to claim 2. When the background attribute is “unique”, the background of this screen is drawn based on the definition information of this screen,
When the background attribute is “reference”, the background of this screen is drawn based on the definition information of the reference screen of this screen,
When the background attribute is “transition source”, the number of types of the background of the screen transitioning to this screen is counted,
When the counted number of types is “0”, the background of this screen is not drawn,
When the counted number of types is “1”, the background of the screen transitioning to this screen is drawn on the background of this screen,
3. The design support system according to claim 2, wherein when the number of types counted exceeds “1”, the screen displays that there is a possibility that a plurality of backgrounds are displayed on the screen. A design support method in a design support system for displaying a design support screen for supporting design of screen transition based on definition information of at least one screen and transition information indicating transition between the at least one screen Because
The design support system includes a processor, a memory, and a storage device, executes a predetermined program,
The storage device manages design definition information including a background attribute indicating the background of the screen ,
The method
When the processor accepts an operation to newly generate the screen of the user, the number of screens to be generated, the background attribute of each screen to be generated, and the state transition to the generated screen are determined , Write to the memory ,
The processor determines the number of screens to be generated and the background attribute of each screen to be generated, the command used to generate the screen, the number of screens selected as a generation source, and the number of screens selected. Determined by the background attribute, written to the memory ,
Design support , wherein the processor determines the state transition to the generated screen based on a command used to generate the screen and the number of screens selected as a generation source, and writes the state transition to the memory Method.

Images