JP2004227105A - Program evaluation method - Google Patents

Program evaluation method Download PDF

Info

Publication number
JP2004227105A
JP2004227105A JP2003011664A JP2003011664A JP2004227105A JP 2004227105 A JP2004227105 A JP 2004227105A JP 2003011664 A JP2003011664 A JP 2003011664A JP 2003011664 A JP2003011664 A JP 2003011664A JP 2004227105 A JP2004227105 A JP 2004227105A
Authority
JP
Japan
Prior art keywords
implemented
methods
virtual function
model diagram
file
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2003011664A
Other languages
Japanese (ja)
Inventor
Takashi Niimoto
隆史 新元
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Ricoh Co Ltd
Original Assignee
Ricoh Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ricoh Co Ltd filed Critical Ricoh Co Ltd
Priority to JP2003011664A priority Critical patent/JP2004227105A/en
Publication of JP2004227105A publication Critical patent/JP2004227105A/en
Pending legal-status Critical Current

Links

Images

Abstract

<P>PROBLEM TO BE SOLVED: To provide a program evaluation method facilitating the management of the progress of an object-directed software development by enabling a person to know the present degree of completion thereof. <P>SOLUTION: It is checked for each method of all classes present in a model drawing whether or not each method is mounted in a source file corresponding thereto. When any line other than a comment is not present in each method, it is determined that this method is not mounted. The number of unmounted methods is totaled, and the ratio to the number of all the methods present in the model drawing is calculated and reported to a user. <P>COPYRIGHT: (C)2004,JPO&NCIPI

Description

【0001】
【発明の属する技術分野】
本発明は、オブジェクト指向言語によるプログラム評価方法に関する。
【0002】
【従来の技術】
近年、プログラムの再利用という観点から、オブジェクト指向によるソフトウェア開発が広く実践されている。オブジェクト指向の分析・設計段階で作成するモデル図(UML表記など)から、ソースコードを自動生成し、これをソフトウェア開発に利用する開発手段も存在する。
【0003】
しかし、こういったソースコード自動生成機能を用いて生成されるソースコードは、主にフレーム部(クラスの宣言、属性の宣言、メソッドの引数や返り値など)のみであり、メソッドの中身は空のままとなる。(メソッドの中身を生成するツールも僅かだが存在する。)
【0004】
ここで問題となるのが、中身が空のメソッドが多数生成され、実際のソフトウェアの完成度が見えづらくなる点である。オブジェクト指向開発では、クラスごとにソース/ヘッダファイルが存在し、従来の手法に比べファイル数が多くなるため、より完成度の把握が難しくなる。従来の手法と異なり、一応関数は存在するため、呼び出し元でコンパイルエラーとならないことも、完成度が見えない要因の一つである。
【0005】
従来、未定義のメソッド、フレーム、スロットの有無をチェックし、未完成状態のオブジェクト指向プログラムにおいての評価を可能とするプログラム評価方法がある(例えば、特許文献1参照)。この方法は、例えばプログラム実行中に未定義のメソッドをコールした場合、そのメソッドの処理すべき内容を表示し、返り値の入力を促すというものである。
【0006】
【特許文献1】
特開平5−265804号公報
【0007】
【発明が解決しようとする課題】
しかしながら、従来の特許文献1記載の発明は、プログラム評価を実行することはできるが、ユーザがソフトウェアの現状の完成度を把握することは困難である。
【0008】
本発明は、上記事情に鑑みてなされたものであり、中身が空のメソッドの割合を算出することで、完成度の把握を支援するプログラム評価方法を提供することを目的とする。
【0009】
また、オブジェクト指向では、継承という概念があり、スーパークラスのメソッドを敢えて空にし、サブクラスにて実装を行うという設計手法が存在する。このとき、敢えて空にしているメソッドも未実装のものとしてカウントしてしまい、正確な完成度が算出できなくなる。そこで、本発明は、スーパークラスのメソッドのうち、敢えて空にしていると考えられるメソッドを実装済みと見なし、完成度を算出するプログラム評価方法を提供することを目的とする。
【0010】
また、現状のソフトウェアの完成度を知ることができるだけでなく、あとどのメソッドを実装する必要があるのかという情報を知ることが必要となる。実際のソフトウェア開発環境においては、このような情報も有効であり、どの部分に遅れが生じているのかを把握することもできる。そこで、本発明は、実装の必要があるメソッドを一覧として出力するプログラム評価方法を提供することを目的とする。
【0011】
【課題を解決するための手段】
かかる目的を達成するために、請求項1記載のプログラム評価方法は、モデル図内に存在する全クラスの各メソッドに対し、対応するソースファイル内でメソッドが実装されているかどうかをチェックする実装チェックステップと、各メソッドについて中かっこで囲まれた、実処理部分にコメント以外の行が存在しない時、そのメソッドは実装されていないと判断する判断ステップと、未実装のメソッドの数を合計し、モデル図内に存在する全メソッド数との割合を算出する算出ステップと、算出結果をユーザに通知する通知ステップとを有することを特徴としている。
【0012】
請求項2記載のプログラム評価方法は、モデル図内に存在する全クラスの各メソッドに対し、対応するソースファイル内でメソッドが実装されているかどうかをチェックする実装チェックステップと、各メソッドの中かっこで囲まれた、実処理部分にコメント以外の行が存在しない時、そのメソッドは実装されていないと判断する判断ステップと、未実装のメソッドの数を合計し、モデル図内に存在する全メソッド数との割合を算出する算出ステップと、算出結果をユーザに通知する通知ステップと、スーパークラスで敢えて空にしていると考えられるメソッド、つまりサブクラスで実装される予定のメソッドが、仮想関数かどうかをチェックする仮想関数チェックステップとを有し、サブクラスで実装される予定のメソッドが仮想関数であれば、メッソドを実装済みと見なすことを特徴としている。
【0013】
請求項3記載のプログラム評価方法は、モデル図内に存在する全クラスの各メソッドに対し、対応するソースファイル内でメソッドが実装されているかどうかをチェックする実装チェックステップと、各メソッドの中かっこで囲まれた、実処理部分にコメント以外の行が存在しない時、そのメソッドは実装されていないと判断する判断ステップと、未実装のメソッドの数を合計し、モデル図内に存在する全メソッド数との割合を算出する算出ステップと、算出結果をユーザに通知する通知ステップと、スーパークラスで敢えて空にしていると考えられるメソッド、つまりサブクラスで実装される予定のメソッドが、仮想関数かどうかをチェックする仮想関数チェックステップと、現状の完成度を算出する過程で、未実装としてカウントしたメソッド名を記憶する記憶ステップとを有し、最終的に完成度を通知する段階で、記憶ステップで記憶された、実装する必要があるメソッド名を列挙して出力することを特徴としている。
【0014】
請求項4記載のプログラム評価方法は、請求項2記載のプログラム評価方法において、サブクラスで実装される予定のメソッドが仮想関数かどうかは、メソッドを持つクラスのヘッダファイルを見ることによりチェックすることを特徴としている。
【0015】
請求項5記載のプログラム評価方法は、請求項4記載のプログラム評価方法において、ヘッダファイルにあるメソッドのプロトタイプ宣言にて、virtual宣言がされていれば、メソッドは仮想関数となることを特徴としている。
【0016】
【発明の実施の形態】
以下、本発明の実施の形態について、添付図面を参照して詳細に説明する。
【0017】
まず、本発明の第1の実施形態について説明する。第1の実施形態では、中身が空のメソッドの割合を算出する。
【0018】
モデル図内に存在する全クラスの各メソッドに対し、対応するソースファイル内でメソッドが実装されているかどうかをチェックする。各メソッドの{ }(中かっこで示される実処理部分)で囲まれた部分で、コメント以外の行が存在しないとき、そのメソッドは実装されていないと判断する。未実装のメソッドの数を合計し、モデル図内に存在する全メソッド数との割合を算出し、ユーザに通知する。
【0019】
第1の実施形態は、例えば図1に示すようなフローで処理を行う。まず、ユーザがソフトウェアの完成度を算出する要求を行う(S101)。ここでは、全メソッド(A)、未実装のメソッド(B)はともにカウントされていない。次に、全メソッド数を算出し(S102)、検索されていないソースファイルがあるかを調べる(S103)。ソースファイルがすべて検索されていれば(S103/NO)、全ファイルの検索を終了し(S105)、完成度を算出し(S108)、完成度の出力を行いユーザに結果を通知する(S110)。
【0020】
未検索ファイルがある場合は(S103/YES)、そのメソッドを検索する(S104)。検索後、そのメソッドのかっこで囲まれた部分にコメント以外の行が存在するかどうかを調べる(S106)。コメント以外の行がある場合(S106/YES)、メソッドを実装済と判断し、1ファイルの検索を終了とし(S109)、再び未検索ファイルがあるかをチェックする(S103)。以後、未検索のファイルがなくなるまで上記処理を繰り返す。
【0021】
コメント以外の行がない場合(S106/NO)、その検索メソッドを未実装と見なし、未実装メソッド数としてカウントし、記憶する(S107)。そして、1ファイルの検索を終了とし(S109)、再び未検索ファイルがあるかをチェックする(S103)。以上の処理を繰り返し、ソースファイルがすべて検索されたら(S103/NO)、全ファイルの検索を終了し(S105)、完成度を算出し(S108)、完成度の出力を行いユーザに結果を通知する(S110)。
【0022】
次に、本発明の第2の実施形態について説明する。第2の実施形態では、仮想関数を除いて完成度を算出する。
【0023】
メソッドが仮想関数かどうかをチェックし、仮想関数であれば実装済みと見なす。仮想関数かどうかは、そのメソッドを持つクラスのヘッダファイルを見ることでチェックする。ヘッダファイルにあるメソッドのプロトタイプ宣言にて、virtual宣言がされていればそのメソッドは仮想関数となる。未実装と判断したメソッドの数を合計し、モデル図内に存在する全メソッド数との割合を算出し、ユーザに通知する。
【0024】
第2の実施形態は、例えば、図2に示すようなフローで処理を行う。まず、第1の実施形態と同様に、ユーザがソフトウェアの完成度を算出する要求を行う(S201)。ここでは、全メソッド(A)、未実装のメソッド(B)はともにカウントされていない。次に、全メソッド数がいくつあるかを算出し(S202)、検索されていないソースファイルがあるかを調べる(S203)。ソースファイルがすべて検索されていれば(S203/NO)、全ファイルの検索を終了し(S205)、完成度を算出し(S208)、完成度の出力を行いユーザに結果を通知する(S210)。
【0025】
未検索ファイルがある場合は(S203/YES)、そのメソッドを検索する(S204)。検索後、そのメソッドのかっこで囲まれた部分にコメント以外の行が存在するかどうかを調べる(S206)。コメント以外の行がある場合(S206/YES)、メソッドを実装済と判断し、1ファイルの検索を終了とし(S212)、再び未検索ファイルがあるかをチェックする(S203)。以後、未検索のファイルがなくなるまで上記処理を繰り返す。
【0026】
コメント以外の行がない場合(S206/NO)、ヘッダファイルからチェック中のメソッドを検索する(S207)。そして、チェック中のメソッドが仮想関数かどうかを調べる(S209)。仮想関数であった場合は(S209/YES)、1ファイルの検索を終了とし(S212)、再び未検索ファイルがあるかをチェックする(S203)。
【0027】
仮想関数でない場合(S209/NO)、その検索メソッドを未実装と見なし、未実装メソッド数としてカウント、記憶する(S211)。そして、1ファイルの検索を終了とし(S212)、再び未検索ファイルがあるかをチェックする(S203)。以上の処理を繰り返し、ソースファイルがすべて検索されたら(S203/NO)、全ファイルの検索を終了し(S205)、完成度を算出し(S208)、完成度の出力を行いユーザに結果を通知する(S210)。
【0028】
次に、本発明の第3の実施形態について説明する。第3の実施形態では、実装する必要があるメソッド名を出力する。
【0029】
第3の実施形態は、上記第1及び第2の実施形態の処理フローにおいて、現状の完成度を算出する過程で、未実装としてカウントしたメソッド名を記憶しておき、最終的に完成度を通知する段階で、記憶していたメソッド名を列挙して出力する。
【0030】
第3の実施形態は、例えば、図3に示すようなフローで処理を行う。まず、第1、第2の実施形態と同様に、ユーザがソフトウェアの完成度を算出する要求を行う(S301)。ここでは、全メソッド(A)、未実装のメソッド(B)はともにカウントされていない。次に、全メソッド数を算出し(S302)、検索されていないソースファイルがあるかを調べる(S303)。ソースファイルがすべて検索されていれば(S303/NO)、全ファイルの検索を終了し(S305)、完成度を算出し(S308)、完成度の出力を行いユーザに結果を通知する(S310)。
【0031】
未検索ファイルがある場合は(S303/YES)、そのメソッドを検索する(S304)。検索後、そのメソッドのかっこで囲まれた部分にコメント以外の行が存在するかどうかを調べる(S306)。コメント以外の行がある場合(S306/YES)、メソッドを実装済と判断し、1ファイルの検索を終了とし(S312)、再び未検索ファイルがあるかをチェックする(S303)。以後、未検索のファイルがなくなるまで上記処理を繰り返す。
【0032】
コメント以外の行がない場合(S306/NO)、ヘッダファイルからチェック中のメソッドを検索する(S307)。そして、チェック中のメソッドが仮想関数かどうかを調べる(S309)。仮想関数であった場合は(S309/YES)、1ファイルの検索を終了とし(S312)、再び未検索ファイルがあるかをチェックする(S303)。
【0033】
仮想関数でない場合(S309/NO)、その検索メソッドを未実装と見なし、未実装メソッド数としてカウント及び記憶し、また、記憶部にチェック中のメソッド名を追加する(S311)。そして、1ファイルの検索を終了とし(S212)、再び未検索ファイルがあるかをチェックする(S303)。以上の処理を繰り返し、ソースファイルがすべて検索されたら(S303/NO)、全ファイルの検索を終了し(S305)、完成度を算出し(S308)、完成度及び記憶していた未実装のメソッド名を列挙して出力を行い、ユーザに結果を通知する(S310)。
【0034】
【発明の効果】
以上の説明から明らかなように、請求項1記載の発明によれば、モデル図内に存在する全クラスの各メソッドに対し、対応するソースファイル内でメソッドが実装されているかどうかをチェックし、各メソッドにおいて、中かっこを用いて囲まれた実処理部分にコメント以外の行が存在しないとき、そのメソッドは実装されていないと判断し、未実装のメソッドの数を合計し、モデル図内に存在する全メソッド数との割合を算出し、ユーザに通知するので、オブジェクト指向によるソフトウェア開発にありがちな、未実装のメソッドが多数存在するような状態においても、現状の完成度を知ることができ、進捗の管理を行うことが容易となる。
【0035】
請求項2記載の発明によれば、スーパークラスで敢えて空にしていると考えられるメソッド、つまりサブクラスで実装される予定のメソッドが仮想関数であるかどうかをチェックし、仮想関数であれば実装済みと見なすことを特徴としているので、より正確な完成度の算出が可能である。
【0036】
請求項3記載の発明によれば、現状の完成度を算出する過程で、未実装としてカウントしたメソッド名を記憶しておき、最終的に完成度を通知する段階で、記憶していたメソッド名を列挙して出力することを特徴としているので、今後実装する必要のあるメソッドが明確になり、プロジェクトレベルだけでなく、各担当レベルの進捗の管理を容易に行うことができる。
【0037】
請求項4記載の発明によれば、請求項2記載の発明において、サブクラスで実装される予定のメソッドが仮想関数かどうかは、メソッドを持つクラスのヘッダファイルを見ることによりチェックすることを特徴としているので、スーパークラスで敢えて空にしているメソッドを実装済みと見なすことができ、より正確な完成度の算出が可能である。
【0038】
請求項5記載の発明によれば、請求項4記載の発明において、ヘッダファイルにあるメソッドのプロトタイプ宣言にて、virtual宣言がされていれば、メソッドは仮想関数となることを特徴としているので、スーパークラスで敢えて空にしているメソッドを実装済みと見なすことができ、より正確な完成度の算出が可能である。
【図面の簡単な説明】
【図1】本発明の第1の実施形態にかかる処理動作を示すフローチャートである。
【図2】本発明の第2の実施形態にかかる処理動作を示すフローチャートである。
【図3】本発明の第3の実施形態にかかる処理動作を示すフローチャートである。
[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a program evaluation method using an object-oriented language.
[0002]
[Prior art]
In recent years, object-oriented software development has been widely practiced from the viewpoint of program reuse. There are also development means for automatically generating a source code from a model diagram (such as UML notation) created in an object-oriented analysis / design stage and using the source code for software development.
[0003]
However, the source code generated using such a source code automatic generation function is mainly a frame part (class declaration, attribute declaration, method arguments and return value, etc.), and the contents of the method are empty. Will remain. (Although there are a few tools that generate the contents of methods.)
[0004]
The problem here is that many empty methods are generated, making it difficult to see the completeness of the actual software. In object-oriented development, a source / header file exists for each class, and the number of files is larger than in the conventional method. Unlike the conventional method, since there is a function for the time being, the fact that no compile error occurs at the caller is also one of the factors that make the degree of completion invisible.
[0005]
2. Description of the Related Art Conventionally, there is a program evaluation method that checks the presence or absence of undefined methods, frames, and slots, and enables evaluation in an unfinished object-oriented program (for example, see Patent Document 1). In this method, for example, when an undefined method is called during the execution of a program, the content to be processed by the method is displayed, and the input of a return value is prompted.
[0006]
[Patent Document 1]
JP-A-5-265804 [0007]
[Problems to be solved by the invention]
However, the conventional invention described in Patent Document 1 can execute program evaluation, but it is difficult for a user to grasp the current degree of perfection of software.
[0008]
The present invention has been made in view of the above circumstances, and it is an object of the present invention to provide a program evaluation method for supporting the grasp of the degree of completion by calculating the ratio of empty methods.
[0009]
Also, in the object orientation, there is a concept of inheritance, and there is a design method in which a method of a super class is intentionally emptied and implemented by a sub class. At this time, even the method that is emptied is counted as unimplemented, and accurate completion cannot be calculated. Therefore, an object of the present invention is to provide a program evaluation method for calculating a degree of completion by regarding a method which is considered to be emptied among the methods of a superclass as being already implemented.
[0010]
In addition, it is necessary not only to know the degree of perfection of the current software, but also to know information on which methods need to be implemented. In an actual software development environment, such information is also effective, and it is possible to grasp which part is delayed. Therefore, an object of the present invention is to provide a program evaluation method for outputting a list of methods that need to be implemented as a list.
[0011]
[Means for Solving the Problems]
In order to achieve the above object, a method for evaluating a program according to claim 1 is an implementation check for checking whether a method is implemented in a corresponding source file for each method of all classes existing in a model diagram. When there is no line other than comment in the actual processing part enclosed in braces for each step and each method, the judgment step to judge that the method is not implemented and the number of unimplemented methods are summed up, The method is characterized in that it has a calculation step of calculating a ratio of the total number of methods existing in the model diagram and a notification step of notifying the user of the calculation result.
[0012]
A program evaluation method according to claim 2, wherein for each method of all classes existing in the model diagram, an implementation check step of checking whether the method is implemented in the corresponding source file, and a curly bracket of each method When there is no line other than the comment in the actual processing part surrounded by, the judgment step to judge that the method is not implemented and the number of unimplemented methods are totaled, and all the methods existing in the model diagram The calculation step of calculating the ratio to the number, the notification step of notifying the user of the calculation result, and whether the method that is supposed to be empty in the superclass, that is, the method to be implemented in the subclass, is a virtual function And a virtual function check step for checking that the method to be implemented in the subclass is a virtual function. If, it is characterized in that considered as already implemented the Messodo.
[0013]
A program evaluation method according to claim 3, wherein for each method of all classes existing in the model diagram, an implementation check step of checking whether the method is implemented in the corresponding source file, and a curly brace of each method When there is no line other than the comment in the actual processing part surrounded by, the judgment step to judge that the method is not implemented and the number of unimplemented methods are totaled, and all the methods existing in the model diagram The calculation step of calculating the ratio to the number, the notification step of notifying the user of the calculation result, and whether the method that is supposed to be empty in the superclass, that is, the method to be implemented in the subclass, is a virtual function In the virtual function check step for checking And a storage step of storing the head name, at the stage of notifying finally complete, stored in the storage step, is characterized by outputting the enumeration method names that must be implemented.
[0014]
According to a fourth aspect of the present invention, in the method of the second aspect, it is determined whether the method to be implemented in the subclass is a virtual function by checking a header file of a class having the method. Features.
[0015]
According to a fifth aspect of the present invention, in the method of the fourth aspect, if a virtual declaration is made in a prototype declaration of a method in a header file, the method becomes a virtual function. .
[0016]
BEST MODE FOR CARRYING OUT THE INVENTION
Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings.
[0017]
First, a first embodiment of the present invention will be described. In the first embodiment, the ratio of empty methods is calculated.
[0018]
For each method of all classes existing in the model diagram, check whether the method is implemented in the corresponding source file. If there is no line other than a comment in the part enclosed in {} (actual processing part indicated by braces) of each method, it is determined that the method is not implemented. Total the number of unimplemented methods, calculate the ratio to the total number of methods existing in the model diagram, and notify the user.
[0019]
In the first embodiment, for example, processing is performed according to the flow shown in FIG. First, the user makes a request to calculate the degree of software completion (S101). Here, all methods (A) and unimplemented methods (B) are not counted. Next, the total number of methods is calculated (S102), and it is checked whether there is a source file that has not been searched (S103). If all the source files have been searched (S103 / NO), the search of all the files is terminated (S105), the completion degree is calculated (S108), the completion degree is output, and the result is notified to the user (S110). .
[0020]
If there is an unsearched file (S103 / YES), the method is searched (S104). After the search, it is checked whether or not a line other than the comment exists in the part of the method enclosed in parentheses (S106). If there is a line other than the comment (S106 / YES), it is determined that the method has been implemented, the search of one file is terminated (S109), and it is checked again whether there is an unsearched file (S103). Thereafter, the above processing is repeated until there is no unsearched file.
[0021]
If there is no line other than the comment (S106 / NO), the search method is regarded as not implemented, counted as the number of unimplemented methods, and stored (S107). Then, the search for one file is terminated (S109), and it is again checked whether there is an unsearched file (S103). The above process is repeated, and when all the source files have been searched (S103 / NO), the search of all the files is completed (S105), the completion degree is calculated (S108), the completion degree is output, and the result is notified to the user. (S110).
[0022]
Next, a second embodiment of the present invention will be described. In the second embodiment, the degree of completion is calculated excluding the virtual function.
[0023]
Checks if the method is a virtual function, and if it is a virtual function, considers it implemented. Check if it is a virtual function by looking at the header file of the class that has the method. If a virtual declaration is made in the prototype declaration of the method in the header file, the method becomes a virtual function. The number of methods determined to be unimplemented is totaled, the percentage of the total number of methods existing in the model diagram is calculated, and the user is notified.
[0024]
In the second embodiment, for example, processing is performed according to the flow shown in FIG. First, similarly to the first embodiment, the user makes a request for calculating the degree of software completion (S201). Here, all methods (A) and unimplemented methods (B) are not counted. Next, the number of all methods is calculated (S202), and it is checked whether there is a source file that has not been searched (S203). If all the source files have been searched (S203 / NO), the search of all the files is terminated (S205), the completion degree is calculated (S208), the completion degree is output, and the result is notified to the user (S210). .
[0025]
If there is an unsearched file (S203 / YES), the method is searched (S204). After the search, it is checked whether a line other than the comment exists in the part of the method enclosed in parentheses (S206). If there is a line other than a comment (S206 / YES), it is determined that the method has been implemented, the search of one file is terminated (S212), and it is checked again whether there is an unsearched file (S203). Thereafter, the above processing is repeated until there is no unsearched file.
[0026]
If there is no line other than the comment (S206 / NO), the header file is searched for the method being checked (S207). Then, it is checked whether the method under check is a virtual function (S209). If it is a virtual function (S209 / YES), the search for one file is terminated (S212), and it is checked again whether there is an unsearched file (S203).
[0027]
If it is not a virtual function (S209 / NO), the search method is regarded as not implemented, and is counted and stored as the number of unimplemented methods (S211). Then, the search for one file is terminated (S212), and it is again checked whether there is any unsearched file (S203). The above processing is repeated, and when all the source files have been searched (S203 / NO), the search of all the files is terminated (S205), the completion degree is calculated (S208), the completion degree is output, and the result is notified to the user. (S210).
[0028]
Next, a third embodiment of the present invention will be described. In the third embodiment, a method name that needs to be implemented is output.
[0029]
In the third embodiment, in the process flow of the first and second embodiments, in the process of calculating the current completion degree, the method name counted as not implemented is stored, and finally the completion degree is calculated. At the notification stage, the stored method names are listed and output.
[0030]
In the third embodiment, for example, processing is performed according to the flow shown in FIG. First, as in the first and second embodiments, the user makes a request to calculate the degree of software completion (S301). Here, all methods (A) and unimplemented methods (B) are not counted. Next, the total number of methods is calculated (S302), and it is checked whether there is a source file that has not been searched (S303). If all the source files have been searched (S303 / NO), the search of all the files is completed (S305), the completion degree is calculated (S308), the completion degree is output, and the result is notified to the user (S310). .
[0031]
If there is an unsearched file (S303 / YES), the method is searched (S304). After the search, it is checked whether a line other than the comment exists in the part of the method enclosed in parentheses (S306). If there is a line other than the comment (S306 / YES), it is determined that the method has been implemented, the search of one file is terminated (S312), and it is checked again whether there is an unsearched file (S303). Thereafter, the above processing is repeated until there is no unsearched file.
[0032]
If there is no line other than the comment (S306 / NO), a method being checked is searched from the header file (S307). Then, it is checked whether the method under check is a virtual function (S309). If it is a virtual function (S309 / YES), the search of one file is terminated (S312), and it is checked again whether there is an unsearched file (S303).
[0033]
If it is not a virtual function (S309 / NO), the search method is regarded as unimplemented, counted and stored as the number of unimplemented methods, and the name of the method being checked is added to the storage unit (S311). Then, the search for one file is terminated (S212), and it is checked again whether there is an unsearched file (S303). The above processing is repeated, and when all the source files have been searched (S303 / NO), the search of all files is terminated (S305), the completion degree is calculated (S308), and the completion degree and the stored unimplemented method are stored. The names are listed and output, and the result is notified to the user (S310).
[0034]
【The invention's effect】
As is apparent from the above description, according to the first aspect of the present invention, for each method of all the classes existing in the model diagram, it is checked whether the method is implemented in the corresponding source file, In each method, if there is no line other than comment in the actual processing part enclosed by curly braces, it is determined that the method is not implemented, the number of unimplemented methods is totaled, and the Calculates the ratio to the total number of existing methods and notifies the user, so even if there are many unimplemented methods that are common in object-oriented software development, it is possible to know the current degree of completion. It is easy to manage the progress.
[0035]
According to the second aspect of the present invention, it is checked whether a method considered to be empty in the superclass, that is, a method to be implemented in the subclass is a virtual function. Since it is characterized by that it can be calculated, it is possible to calculate the degree of perfection more accurately.
[0036]
According to the third aspect of the present invention, in the process of calculating the current degree of completion, the method name counted as not implemented is stored, and the stored method name is finally notified at the stage of notifying the degree of completion. Is enumerated and output, so the methods that need to be implemented in the future are clarified, and it is easy to manage not only the project level but also the progress of each charge level.
[0037]
According to the invention described in claim 4, in the invention described in claim 2, whether a method to be implemented in the subclass is a virtual function is checked by looking at a header file of a class having the method. Therefore, it is possible to consider that the method that is emptied in the super class is already implemented, and it is possible to calculate the completeness more accurately.
[0038]
According to the invention described in claim 5, in the invention described in claim 4, the method becomes a virtual function if the virtual declaration is made in the prototype declaration of the method in the header file. The methods that are emptied by the superclass can be regarded as implemented, and the degree of completion can be calculated more accurately.
[Brief description of the drawings]
FIG. 1 is a flowchart illustrating a processing operation according to a first embodiment of the present invention.
FIG. 2 is a flowchart illustrating a processing operation according to a second embodiment of the present invention.
FIG. 3 is a flowchart illustrating a processing operation according to a third embodiment of the present invention.

Claims (5)

モデル図内に存在する全クラスの各メソッドに対し、対応するソースファイル内でメソッドが実装されているかどうかをチェックする実装チェックステップと、
前記各メソッドの実処理部分にコメント以外の行が存在しない時、そのメソッドは実装されていないと判断する判断ステップと、
未実装のメソッドの数を合計し、前記モデル図内に存在する全メソッド数との割合を算出する算出ステップと、
前記算出結果をユーザに通知する通知ステップと、
を有することを特徴とするプログラム評価方法。
For each method of all classes existing in the model diagram, an implementation check step for checking whether the method is implemented in the corresponding source file,
When there is no line other than a comment in the actual processing part of each method, a determining step of determining that the method is not implemented,
A calculation step of summing the number of unimplemented methods and calculating a ratio with the total number of methods existing in the model diagram,
A notification step of notifying a user of the calculation result,
A program evaluation method comprising:
モデル図内に存在する全クラスの各メソッドに対し、対応するソースファイル内でメソッドが実装されているかどうかをチェックする実装チェックステップと、
前記各メソッドの実処理部分にコメント以外の行が存在しない時、そのメソッドは実装されていないと判断する判断ステップと、
未実装のメソッドの数を合計し、前記モデル図内に存在する全メソッド数との割合を算出する算出ステップと、
前記算出結果をユーザに通知する通知ステップと、
スーパークラスで敢えて空にしていると考えられるメソッド、つまりサブクラスで実装される予定のメソッドが、仮想関数かどうかをチェックする仮想関数チェックステップとを有し、
前記サブクラスで実装される予定のメソッドが仮想関数であれば、前記メソッドを実装済みと見なすことを特徴とするプログラム評価方法。
For each method of all classes existing in the model diagram, an implementation check step for checking whether the method is implemented in the corresponding source file,
When there is no line other than a comment in the actual processing part of each method, a determining step of determining that the method is not implemented,
A calculation step of summing the number of unimplemented methods and calculating a ratio with the total number of methods existing in the model diagram,
A notification step of notifying a user of the calculation result,
A virtual function check step for checking whether a method considered to be empty in the superclass, that is, a method to be implemented in the subclass, is a virtual function;
If the method to be implemented in the subclass is a virtual function, the method is regarded as implemented, and the method is evaluated.
モデル図内に存在する全クラスの各メソッドに対し、対応するソースファイル内でメソッドが実装されているかどうかをチェックする実装チェックステップと、
前記各メソッドの実処理部分にコメント以外の行が存在しない時、そのメソッドは実装されていないと判断する判断ステップと、
未実装のメソッドの数を合計し、前記モデル図内に存在する全メソッド数との割合を算出する算出ステップと、
前記算出結果をユーザに通知する通知ステップと、
スーパークラスで敢えて空にしていると考えられるメソッド、つまりサブクラスで実装される予定のメソッドが、仮想関数かどうかをチェックする仮想関数チェックステップと、
現状の完成度を算出する過程で、未実装としてカウントしたメソッド名を記憶する記憶ステップとを有し、
最終的に完成度を通知する段階で、前記記憶ステップで記憶された、実装する必要があるメソッド名を列挙して出力することを特徴とするプログラム評価方法。
For each method of all classes existing in the model diagram, an implementation check step for checking whether the method is implemented in the corresponding source file,
When there is no line other than a comment in the actual processing part of each method, a determining step of determining that the method is not implemented,
A calculation step of summing the number of unimplemented methods and calculating a ratio with the total number of methods existing in the model diagram,
A notification step of notifying a user of the calculation result,
A virtual function check step to check whether the method that is supposed to be empty in the superclass, that is, the method to be implemented in the subclass, is a virtual function,
In the process of calculating the current perfection, has a storage step of storing the method name counted as not implemented,
A method for evaluating a program, comprising: enumerating and outputting the names of the methods that need to be implemented and stored in the storage step at the stage of finally notifying the completion degree.
前記サブクラスで実装される予定のメソッドが仮想関数かどうかは、前記メソッドを持つクラスのヘッダファイルを見ることによりチェックすることを特徴とする請求項2記載のプログラム評価方法。3. The program evaluation method according to claim 2, wherein whether the method to be implemented in the subclass is a virtual function is checked by looking at a header file of the class having the method. 前記ヘッダファイルにある前記メソッドのプロトタイプ宣言にて、virtual宣言がされていれば、前記メソッドは仮想関数となることを特徴とする請求項4記載のプログラム評価方法。5. The program evaluation method according to claim 4, wherein the method becomes a virtual function if a virtual declaration is made in a prototype declaration of the method in the header file.
JP2003011664A 2003-01-20 2003-01-20 Program evaluation method Pending JP2004227105A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2003011664A JP2004227105A (en) 2003-01-20 2003-01-20 Program evaluation method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2003011664A JP2004227105A (en) 2003-01-20 2003-01-20 Program evaluation method

Publications (1)

Publication Number Publication Date
JP2004227105A true JP2004227105A (en) 2004-08-12

Family

ID=32900499

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2003011664A Pending JP2004227105A (en) 2003-01-20 2003-01-20 Program evaluation method

Country Status (1)

Country Link
JP (1) JP2004227105A (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013025604A (en) * 2011-07-22 2013-02-04 Mitsubishi Electric Corp Information processor, information processing method and program

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013025604A (en) * 2011-07-22 2013-02-04 Mitsubishi Electric Corp Information processor, information processing method and program

Similar Documents

Publication Publication Date Title
US8996349B2 (en) Synchronizing an abstract model and source code
US8667462B1 (en) Model and subsystem function signatures
US8200807B2 (en) Non-blocking local events in a state-diagramming environment
US20120084761A1 (en) Interprocedural Exception Method
US20090049080A1 (en) Relationship management for data modeling in an integrated development environment
Lettrari et al. Scenario-based monitoring and testing of real-time UML models
CN111124379B (en) Page generation method and device, electronic equipment and storage medium
Dam et al. Supporting change propagation in UML models
Klarlund et al. Formal design constraints
US7721276B2 (en) Computer-implemented method, system and program product for comparing application program interfaces (APIs) between JAVA byte code releases
Crocker Safe object-oriented software: the verified design-by-contract paradigm
Fraternali et al. Automating function point analysis with model driven development
EP2101292A1 (en) Creating parallel control flows in business process models
Bodeveix et al. Extending OCL for verifying UML models consistency
US8136094B2 (en) Relationship management for data modeling in an integrated development environment
JP2004227105A (en) Program evaluation method
Süß et al. Implementing irregular parallel algorithms with OpenMP
Song et al. Toward a model-based approach to dynamic adaptation of composite services
JP2007265005A (en) Review support apparatus, review support method and review support program
Voudouris et al. Integrating heuristic search and one-way constraints in the iopt toolkit
te Brinke et al. A tool-supported approach for modular design of energy-aware software
JP5243908B2 (en) Computer system, method and computer program for verifying model quality
Karamti et al. Hierarchical modeling with dynamic priority time petri nets for multiprocessor scheduling analysis
JP2004252512A (en) Method and device for retrieving program component
JP2000039998A (en) Method for supporting change of object oriented software component, device therefor and storage medium stored with program for supporting change of object oriented software component

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20050707

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20080415

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20080512

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20080624