Computer graphics processing and selective visual display system – Computer graphics processing – Graph generating
Reexamination Certificate
2000-02-01
2001-04-17
Vo, Cliff N. (Department: 2671)
Computer graphics processing and selective visual display system
Computer graphics processing
Graph generating
C345S215000
Reexamination Certificate
active
06219065
ABSTRACT:
BACKGROUND OF THE INVENTION
The present invention relates to acquirement of a requirement in developing application to be developed by using a computer, and in particular to a method for visualizing, defining and acquiring the requirement, and a method for visually displaying the requirement. The “acquiring” means interactively effecting various amendments and alterations upon the visualized requirement and definitely fixing the finally completed requirement.
In development of electronic devices such as computers, support using software is indispensable. Especially in the stage of study of a new kind of machine or a new scheme, it is important to input sketches of various device configurations as models, perform simulation, evaluate the results, repeat them, and examine closely the design principle. Furthermore, it is important to transmit the design principle to the persons concerned accurately and intelligibly.
Likewise, even in the development of a software application system, it has become important business in the design stage of the requirement to produce interactively the requirement and present the requirement to customers in an easily understandable visual form.
On the other hand, creation of the requirement in system development is performed as follows: the customer is asked about the requirement by a system engineer who acquires the requirement from a customer and definitely fixes system specifications; on the basis thereof, the system engineer creates a requirement document; the requirement document is evaluated by the customer; and these steps are repeated until alterations disappear and a final requirement document which satisfies the customer's need is completed. On the basis of the requirement document definitely fixed by the customer and the system engineer, system developers implement the system. In the case where a difference has occurred between the implemented system and the customer's request, the requirement document is recreated and the system is also reimplemented.
For example, in a method described in “ODETTE: Design support construction environment based on object-oriented CLOS,” Object-oriented Software Technique Symposium Record, pp. 1-11 (1991), Information Processing Society of Japan, a part which is a design subject is first defined by a program using a programming language and the substance of the procedure of the part is also set by describing a program. Then in order to set display figure data of the part, the operator arbitrarily draws a figure by using a mouse or the like and associates the figure with part data previously programmed and defined. Then an animation program is defined in the program and is set in part attribute definition data and display figure data. In setting the animation program, a procedure for calling the animation is first set in the above described part attribute definition data. And a procedure for the animation is defined by using the above described display figure data and is set in the above described display figure data. Then the operator generates part attribute data on a computer memory by interactive operation. If generation is completed, simulation is executed by executing various procedures of the part attribute data. The result of that simulation is displayed by executing the animation program. To be concrete, execution of the animation program is conducted as described hereafter.
First of all, the animation call procedure is executed, and the animation procedure is called and executed. By execution of the animation procedure, the display figure data is updated. Thereby, the figure is modified so as to conform to new display figure data, and the animation is executed.
Furthermore, in a conventional technique described in JP-A-7-44729, a subject part of a designed system is defined by a data item held by the part and a procedure is defined by programming using the programming language, thereby providing an environment for interactively defining the display figure of the part and operation at the time of implementation of the display figure. Furthermore, simulation of the procedure of the part is executed, and the operation image of the display figure at the time of implementation of the part is displayed in an animation form. Thus, the requirement in the design stage and the image at the time of implementation are confirmed visually, and the requirement is evaluated. For producing requirement satisfying the customer's need more closely, visual evaluation of the requirement must be conducted repetitively.
As for description of the requirement, there is a description method called scenario. The scenario is a method of directly describing the external operation of the system from the view point of the user. For example, in Pei Hsia et. al., “Formal Approach to Scenario Analysis”, IEEE Software, March 1994, pp. 33-41 (1994) (paper 2), there are shown, by taking a telephone switching system as an example, operation names of the end user, inputting and confirmation by using a tree of a scenario of system function call, and a procedure leading to phototyping based on a group of inputted scenarios.
In application of the above described conventional technique, the system engineer must have a skill of programming. In the conventional business form, however, the person who hears requirement from the customer, for example, typically does not need the programming technique. For visualizing the requirement, therefore, the person must learn the programming technique. As a result, it was rather difficult for many system engineers to use the conventional technique.
Furthermore, in the above described conventional technique, the program of components must be redefined when a change especially concerning components has occurred in the requirement. Typically, however, it was not easy to add the change while evaluating the requirement.
Furthermore, for visualizing and producing the requirement, it was necessary to abstract contents heard from the customer as a procedure, perform programming, and input it. Typically, the abstracting process for transferring the requirement of the real world to the world on the computer is not easy for the system engineer who hears requirement in a position near the real world.
A change in the requirement needed when the customer evaluated the created visualizing requirement such as an addition of exceptional processing was difficult to effect because the requirements of the whole development subject are produced as a program at a time.
If the whole requirement of the development subject is produced, it is expected that a large number of partial visualized requirements inputted by the user are generated. Furthermore, there is also a possibility that a plurality of users perform the inputting operation. Therefore, it can be expected that it becomes difficult for the user to grasp all of inputted visualized requirements and grasp a visualized requirement edited to create a requirement conforming to the customer's need.
Furthermore, it was not easy to grasp, out of a large number of scenarios, relations between visualized requirements specified intentionally by a user when inputting the visualized requirement.
Furthermore, in the scenario describing method of the paper 2, consideration was not given to showing the scenario intelligibly and it was difficult for the user to confirm each scenario. In addition, since only the operation name and function call were described, it was difficult to represent the requirement concerning the data item flow and changes of the terminal screen. Furthermore, sufficient reference was not made to the method for efficiently generating phototyping from a group of inputted scenarios. Furthermore, since a group of scenarios were inputted by means of one tree, display and interactive editing were difficult in complicated and various scenarios under restrictions of the screen size.
SUMMARY OF THE INVENTION
A primary object of the present invention is to define components and a procedure between components with programless interactive operations when th
Kubo Shoichi
Mashita Yuichi
Saito Miho
Takahashi Hisashi
Yuura Katsuhiko
Hitachi , Ltd.
Mattingly Stanger & Malur, P.C.
Vo Cliff N.
LandOfFree
Method for inputting and acquiring requirement does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method for inputting and acquiring requirement, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method for inputting and acquiring requirement will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2435179