JP2014059775A - プログラム構造評価システム、プログラム - Google Patents

Abstract

【課題】プログラムを解析・点数化して容易に評価可能とすると共にその為に必要なテーブル情報を半自動的に生成する。
【解決手段】解析対象のプログラムソース２８に対する（２）プログラム解析処理と、その後の（３）階層登録などや、（４）アクセス違反抽出などや、（５）アクセス違反例外登録などの処理によって、階層定義テーブル（作成中）２１、アクセス違反例外登録ファイル（作成中）２６を、作成・更新していく。最後に、アクセス違反例外登録ファイル（作成中）２６にして任意の階層違反の許容の情報を登録させることで、アクセス違反例外登録ファイル（登録）２７を生成すると共に、これと階層定義テーブル（作成中）２１を用いて階層定義テーブル（登録）２２を生成する。
【選択図】図１０

Description

本発明は、プログラム構造を解析・評価する装置などに関する。

ソフトウェアの開発では、まず最初にソフトウェア全体の構造を決め、この構造に従ってプログラムの実装を行っている。
新規開発では、ソフトウェア構造に従って作成したものが作られるが、担当者によっては構造を無視して安直に他の機能の変数を書き換えたりすることがある。また、仕様書どおりの構造で作成されたプログラムが、派生開発や障害発生時の緊急対応などにより、担当者が全体構造を理解しないままその場しのぎでプログラムを修正し、その変更内容のレビューすることもなくソフトウェアを提供してしまうことがある。その結果、いわゆるスパゲッティプログラムとなることで、修正の影響範囲が分からなくなり、想定外機能の不具合が発生し、品質保証のための作業工数の増大が発生する。最悪の場合は、顧客の信用を失墜し大きな損害を与えることがある。

本来は、全体構造を理解した上で修正し、全体構造を理解したレビューアによるレビューが望ましいことは分かっているが、実際には、以下の原因により実施されないことも多い
・開発メンバーの入替りで、全体構造（初期の設計思想）を十分理解できていない
・短納期により、有識者によるレビューをしていない
・レビューアが忙しく、レビューができない
ここで、プログラムを解析管理または点数評価する技術として、例えば特許文献１、２に記載の従来技術が知られている。

特許文献１の従来技術は、プログラム中における共通構造を解析することにより、共通部分を明示したプログラム構造図の生成や、プログラム構造における共通部分の再利用化を容易なものとする。

また、特許文献２の従来技術は、各評価指標を点数評価することにより品質向上が必要とされる順に優先度付けし、精度が高く効率的な品質評価と、効率的且つ効果的な品質向上作業を図ることができる。上記点数評価は、チェックリスト件数密度、不良件数密度、カバレージ率、規模、難易度、不良の重要度や不良分析コード等の各々の評価項目単位に、評価点数算出基準に従い評価点数を算出するものである。

特開２００７−１１５１５５号公報 特開２０００−５６９６１号公報

ここで、従来より、プログラム自体を品質特性に従って点数化するツールは存在する（例えばオージス総研の「Ａｄｑｕａ（アドクア；登録商標）」や、東陽テクニカ等の「ｅＸｑｕｔｏ（登録商標）」等）。例えばＡｄｑｕａ（アドクア）は、組込みソフトウェアの品質を定量的に評価できるツールである。具体的には、ソフトウェアを「信頼性」「効率性」「保守性」「移植性」「再利用性」の５つの品質特性の観点で得点化する。

ここで、上記ソフトウェア構造の規定として、例えば、複数の機能より成るソフトウェアにおける機能間のアクセス（呼び出し等）に係る制限事項が設けられたものがある。これは、例えば関数間のアクセスに係る制限や、関数から変数へのアクセスに係る制限等である。あるいは、上記複数の機能が階層構造になっている場合には、この様な階層に係る制限事項も含まれる。

この様な意味でのソフトウェア構造の規定（制限）に従ってプログラムが作成する場合も、当然、何らかの理由で違反が生じることは有り得る。違反件数の多さは、品質に影響する。また、過去に作成されたプログラムを改造する場合には、少なくとも品質を落とさないようにすることが望まれる。

例えば、オブジェクト指向プログラムの場合、クラス図などを作成して、これに従ってプログラム作成や継承等を行うが、古いソフトウェア等はこの様なモデル化設計思想ではなく旧来の構造化設計思想に基づいて作成されており、また、この様な古いソフトウェア（レガシー資産）を再利用するために改造を行い新規ソフトウェアとして作成する場合もある。この様な過去の古いソフトウェアに対して上記ソフトウェア構造に従った評価を行うと、違反件数が多数となる場合が少なくない。そして、この様な過去の古いソフトウェアから改造版等を作成する場合、違反であることが分かっていても修正することが困難な場合が少なくなく、現状維持（それ以上違反を増やさない）が出来ればよいとする場合がある。

以上のことから、上述した意味でのソフトウェア構造に従ったプログラム作成が行われているか否か（例えば、最低限、現状維持できているか等）の判断を、プログラム全文をチェックして評価するような手間が掛かる作業を行う必要なく、行えるようにすることが望まれる。これは、例えば、上記違反に関して点数化を行うことで、客観的且つ的確な判断が行えるようにすることが望まれる。

一方、上述したＡｄｑｕａ等の既存ツールや、特許文献１，２の従来技術では、上述した意味でのソフトウェア構造の規定、すなわち上記複数の機能より成るソフトウェアにおける機能間のアクセスに係る制限事項や階層に係る制限事項に関して、点数化して評価することは何等考えられていない。

また、上述した違反に関する点数化やソフトウェア評価の為の必要となるユーザの手間は、出来るだけ軽減されるようにすることが望まれる。あるいは、上述したレガシー資産を再利用して新規ソフトウェア作成を行った場合や、ソフトウェアのバージョンアップを行った場合に、違反の増減などを的確に（見逃すことなく）行えるようにすること等も望まれる。

本発明の課題は、複数の機能より成るソフトウェアにおける機能間のアクセスに係る制限があるソフトウェア構造設計に従ったプログラム作成が行われたか否かについて、プログラムを解析・点数化することで容易に評価可能とし、更に、その為のユーザの手間を軽減でき、あるいは新規に発生したアクセス違反を見過ごすことが無くなるプログラム構造評価システム等を提供することである。

本発明のプログラム構造評価システムは、任意のソフトウェアについて所定の評価を行うためのコンピュータシステムにおいて、複数の機能より成るソフトウェアの機能間のアクセスに係る制限に従って、呼び出し元となる機能と呼び出し先となる機能の関数種別／変数種別との組み合わせである機能ペア毎に、違反の有無、または／及び、違反許容数が格納された違反有無情報を記憶する違反有無情報記憶手段と、評価対象のソフトウェアのプログラムソース文を順次参照して、任意の機能から他の機能の任意の関数／変数を呼び出す処理を検出する毎に、該呼び出し先の関数／変数の関数種別／変数種別を判別して、さらに前記違反有無情報を参照して、該呼び出しが違反か否かを判定する違反判定手段と、前記違反判定手段による判定結果に基づいて、前記各機能毎または／及び前記評価対象のソフトウェア全体の違反件数を集計する集計手段と、該集計手段による違反件数の集計結果に基づいて、前記評価対象のソフトウェア全体または／及びその各機能毎の評価点数を算出する評価点数算出手段と、予め、前記評価対象のソフトウェアに基づいて、前記違反有無情報を生成して前記違反有無情報記憶手段に記憶させる違反有無情報生成手段とを有する。

本発明のプログラム構造評価システム等によれば、複数の機能より成るソフトウェアにおける機能間のアクセスに係る制限があるソフトウェア構造設計に従ったプログラム作成が行われたか否かについて、プログラムを解析・点数化することで容易に評価可能とし、更に、そのためのユーザの手間を軽減でき、あるいは新規に発生したアクセス違反を見過ごすことが無くなる。

本例のプログラム評価システム全体の構成図である。 ソフトウェア構造（階層と機能）の一例を示す図である。 階層定義テーブルのフォーマット例である。 階層定義テーブル（登録）の具体例である。 アクセス違反例外登録ファイル（登録）の具体例である。 （ａ）はアクセス違反計数ファイル、（ｂ）は集計結果の具体例である。 （ａ）、（ｂ）は、動作情報定義テーブルに設定される情報の一例である。 （ａ）は重み付け後の集計結果、（ｂ）はアクセス違反点数化ファイルの具体例である。 偏差値算出処理の具体例を示す図である。 階層定義テーブルとアクセス違反例外登録ファイルの半自動作成に係る処理・作業の流れを示す図である。 プログラムソースの具体例である。 「階層登録＆入力チェック」の設定手順の具体例である。 “アクセス違反例外の許可登録”の設定手順の具体例である。 アクセス違反判別に係る作業・処理の流れを示す。 サーバメイン処理部のフローチャート図である。 定義アクセスタスク部の処理フローチャート図である。 定義生成タスク部の処理フローチャート図である。 （ａ）は“プログラム解析処理”のフローチャート図、（ｂ）はそのステップＳ６１の詳細フローチャート図である。 階層登録チェック処理のフローチャート図である。 階層違反例外検出処理のフローチャート図である。 “アクセス違反例外登録ファイル作成処理”のフローチャート図である “階層定義テーブル比較処理” のフローチャート図である。 “アクセス例外許可ファイル比較処理”のフローチャート図である。 点数化タスク部１２の処理フローチャート図である。 ルールに基づくプログラム例である。

以下、図面を参照して本発明の実施の形態について説明する。
図１は、本例のプログラム構造評価システム全体の構成図であって、特に管理サーバの機能構成を示す図である。

図示のプログラム構造評価システムは、作業者が操作するための操作端末１と、任意のプログラムに関するソフトウェア構造に係る評価（点数化等）を実行する管理サーバ１０とが、ネットワーク２に接続された構成となっている。ネットワーク２は、例えばＬＡＮやインターネット等の一般的なネットワークであってよい。ネットワーク２を介して、操作端末１と管理サーバ１０間でデータ／コマンド等を送受信する。

但し、この例に限らない。例えば管理サーバ１０単体でプログラム構造評価システムを構成するものであってもよい。勿論、この場合、操作端末１の機能も管理サーバ１０が有することになる。例えば、後述する各種要求は、例えば管理サーバ１０のキーボード等を開発者等が操作して所望の指示を行うことで、管理サーバ１０自身がサーバメイン処理部１１に対してこの指示に応じた要求を発行することになる。

操作端末１は、例えば一般的なパソコン等であって、特に図示しないが作業者（ユーザ）に任意のコマンド・ボタンを選択・指定させる為の画面等を表示する機能や、ユーザが選択・指定したコマンド・ボタンに応じた要求（コマンド）を、ネットワーク２を介して管理サーバ１０へと送信する機能等を有する。

上記要求の種類としては、たとえば後述する“点数化要求”や“定義設定要求”や“定義生成要求”等がある。
管理サーバ１０は、サーバメイン処理部１１、点数化タスク部１２、定義アクセスタスク部１３、定義生成タスク部１４の各種機能部を有する。これら各種機能部の処理機能は、不図示のＣＰＵ等が、不図示の記憶装置（ハードディスク、メモリ等）に予め記憶されている所定のアプリケーションプログラムを読出し・実行することにより実現される。これら各種機能部や上記各種要求に応じた処理については、後に各種フローチャート図等を参照して説明するものとする。

また、管理サーバ１０は、上記記憶装置等に、偏差値計数ファイル１５を記憶・保持している。
また、管理サーバ１０は、上記記憶装置等に、各製品（ソフトウェア）毎に対応する各種情報／プログラムを記憶する（尚、この記憶には、一時的に生成される情報等の記憶も含まれる）。

すなわち、図示の例では製品Ａと製品Ｂのそれぞれについて、階層定義テーブル（作成中）２１、階層定義テーブル（登録）２２、動作情報定義テーブル２３、アクセス違反計数ファイル２４、アクセス違反点数化ファイル２５、アクセス違反例外登録ファイル（作成中）２６、アクセス違反例外登録ファイル（登録）２７の各種テーブルと、プログラムソース２８等を記憶する。プログラムソース２８は、例えば製品Ａを構成する複数のプログラムファイルから構成される。

尚、図では製品Ａについての各種情報／プログラムのみ示すが、製品Ｂについても略同様に、その製品に対応する各種情報／プログラムが記憶される。
サーバメイン処理部１１は、操作端末１からの何らかの要求を受け付けて、この要求に応じて点数化タスク部１２、定義アクセスタスク部１３、定義生成タスク部１４の何れかを呼び出して処理実行させる。但し、以下の説明では、サーバメイン処理部１１については逐一述べずに、省略する場合もあるものとする。

点数化タスク部１２は、操作端末１からの要求が任意の製品のプログラムソース２８に関する評価（点数化等）であった場合に、サーバメイン処理部１１から呼び出されて、当該プログラムソース２８の評価（点数化等）を行い、場合によっては更に偏差値等を作成する。尚、点数化タスク部１２の上記点数化等の処理に伴って、上記アクセス違反計数ファイル２４、アクセス違反点数化ファイル２５が生成される。詳しくは後述する。

定義アクセスタスク部１３は、操作端末１からの要求などに応じて、テーブルやファイル等に対するデータアクセス（読み書き）処理を実行・管理する。
定義生成タスク部１４は、操作端末１からの要求などに応じて、該当する処理（プログラム）を読み出すなどして、設定のチェックや設定データの自動生成等を実行・管理する。

尚、本例では、サーバメイン処理部１１が、定義アクセスタスク部１３や定義生成タスク部１４の管理を行うものとするが、この例に限らない。
また、上記各種テーブル／ファイルは、例えば下記のように分類される。
（ａ） 作業用ファイル
・階層定義テーブル（作成中）２１
・アクセス違反例外登録ファイル（作成中）２６
（ｂ） 階層評価時に定義されているテーブル
・階層定義テーブル（登録）２２
・動作情報定義テーブル２３
（ｃ） 階層評価を行なうために作成されるファイル
・アクセス違反例外登録ファイル（登録）２７
・アクセス違反計数ファイル２４
・アクセス違反点数化ファイル２５
・偏差値計数ファイル１５
ここで、図２に、ソフトウェア構造（階層と機能）の一例を示す。

図２のソフトウェア構造例は、複数の機能が階層構造となっているソフトウェア構造の一例であり、第一階層（最下層）、第二階層（中間層）、第三階層（上位層）の３階層あり、各階層毎に一例として２つの機能が存在するものとする。すなわち、第一階層には、機能１−１と機能１−２がある。同様に、第二階層には機能２−１と機能２−２があり、第三階層には機能３−１と機能３−２がある
図２のソフトウェア構造の具体例としては、例えばソフトウェアが何らかの所謂“組込みソフトウェア”である場合が考えられる。尚、よく知られているように、“組込みソフトウェア”とは、家電製品や産業機器に組み込まれた特定の機能を提供するためのコンピュータシステム（組込みシステム）上のソフトウェアである。上記Adqua等は、主に組込みソフトウェアの品質評価に用いられるものである。

ここで、組込み用のプログラムに関するソフトウェア構造の一例として、機能が、例えばアプリケーション、ミドル（ミドルウェア）、ＯＳ（ドライバ）に階層化・分類される場合がある。つまり、階層としては、アプリケーションが上位層、ミドルが中間層、ＯＳ（ドライバ）が最下層（下位層）となっている。そして、基本的には任意の階層の任意の機能が、自己と同じ階層の他の機能または１段下の階層の他の機能を呼び出すことになる。このうち１段下の階層の呼び出しに関しては、上記の例では、アプリケーションがミドルを呼び出し、ミドルがＯＳ（ドライバ）を呼び出すものとなる。

上記のことは、換言すれば、２段下の階層の機能を呼び出すことは違反となる。つまり、アプリケーションがＯＳ（ドライバ）を呼び出すことは違反となる。更に、上位側の機能を呼び出すことも違反となる。すなわち、ミドルがアプリケーションを呼び出すことや、ＯＳ（ドライバ）がミドルやアプリケーションを呼び出すことは、違反となる。

尚、後述するように、任意の機能に係るローカル変数／ローカル関数を他の機能が呼ぶ出すことも違反となる。
尚、上記任意の機能から他の機能の呼び出しは、詳細には、例えば任意の機能の関数から他の機能の関数の呼び出しや、任意の機能の関数から他の機能の変数の呼び出し等となる。但し、これに限らず、自機能内での呼び出しも行われる。つまり、任意の機能の関数から同じ機能内の他の関数の呼び出しや、任意の機能の関数から同じ機能内の任意の変数の呼び出し等となる。但し、基本的に自機能内での呼び出しは違反とはならないので、本説明では自機能内での呼び出しに係る説明を省略する場合もあるものとする。

上記各機能は、それぞれ、プログラムソース２８を構成する複数のプログラムファイルにより実現される。各プログラムファイルのプログラム記述に用いられる関数、変数の種類（種別）は、本例では図２に示すように、ＡＰＩ関数（グローバル関数）、ローカル関数、グローバル変数、ローカル変数等であり、それぞれ下記の特徴と有する。
（i）ＡＰＩ関数 ；機能外からでもアクセスできる関数
（ii）ローカル関数 ；その機能内でのみアクセスできる関数
（iii）グローバル変数 ；機能外からでもアクセスさせることを前提とした変数
（iv）ロ−カル変数 ；その機能内でのみ使用する変数
基本的に、任意の機能におけるローカル関数やローカル変数を、他の機能から呼び出すことは、上記階層構造に関係なく、違反となる。

尚、上記ＡＰＩ（Application Program Interface）関数やローカル関数は関数種別の一例、上記グローバル変数やローカル変数は変数種別の一例と言える。
以上、図２を用いて説明したことが、上述した「複数の機能より成るソフトウェアにおける機能間のアクセスに係る制限事項や階層に係る制限事項」の具体例である。本システムでは、評価対象のソフトウェア（プログラムソース２８）に関して、「複数の機能より成るソフトウェアにおける機能間のアクセスに係る制限事項や階層に係る制限事項」に係る評価のための点数化を行うことができる。

後述するように、本例では、上記関数種別／変数種別毎に違反件数の集計や評価点数の算出等を行うものであるが、この例に限らない。尚、本例では、基本的には（違反が無い限りは）、全ての関数はＡＰＩ（関数）とローカル関数の何れかに属するものであり、全ての変数はグローバル変数とローカル変数の何れかに属するものとするが、この例に限らない。

例えば開発者等が、事前に、上記図２に示すソフトウェア構造（階層と機能に係る制限事項）に従って、階層定義テーブル（登録）２２を作成する。この階層定義テーブル（登録）２２を用いて、点数化・評価等が行われることになる。ここで、階層定義テーブル（登録）２２は、開発者等のユーザが手作業でデータ入力して作成してもよいが、半自動的に作成されるものであってもよい（後述するように、ユーザが手作業で入力するデータは非常に少なくてすむ）。

これは、管理サーバ１０において、階層定義テーブル（作成中）２１という階層定義テーブルの作成途中の状態を経て、最終的に階層定義テーブルが完成したら階層定義テーブル（登録）２２として保存されるものである。また、アクセス違反例外登録ファイル（登録）２７が作成され、このファイル２７が上記階層定義テーブルの半自動生成の為に用いられる。尚、これについても、アクセス違反例外登録ファイル（作成中）２６というアクセス違反例外登録ファイルの作成途中の状態を経て、最終的にアクセス違反例外登録ファイルが完成したらアクセス違反例外登録ファイル（登録）２７として保存されるものである。また、アクセス違反例外登録ファイル（作成中）２６は、アクセス違反の増減の判別の為に利用できる。詳しくは後述する。尚、アクセス違反例外登録ファイル（登録）２７も、半自動生成されるものであり、ユーザの作業負担を軽減できる。

尚、開発者等による階層定義テーブルの作成作業は、操作端末１側で行っても良いし、管理サーバ１０側で行っても良いが、何れの場合でも上記管理サーバ１０が階層定義テーブルを半自動生成するので、入力作業の手間が軽減され、作成効率が向上する。

尚、階層定義テーブル（登録）２２は、例えば、複数の機能が階層構造となっているソフトウェア構造に従って、呼び出し元となる任意の機能と、呼び出し先となる任意の機能の関数種別／変数種別との組み合わせ（ペア）毎に、違反の有無や許容違反数が登録されたテーブルである。階層定義テーブル（登録）２２は、アクセス違反を検出するための設定テーブルである。

ここで、図３に階層定義テーブルのフォーマット例を示す。尚、図３は、階層定義テーブル（作成中）２１の具体例を示すものということもできる。つまり、未だ作成途中であり完成していない。また、図４には、階層定義テーブル（登録）２２の具体例を示す。これは、作成途中ではなく、完成済みの状態を示すものと言える。尚、図３では図示の呼び出し元３６について省略して示すが、実際には例えば図４に示すように呼び出し元３６には各機能（図示の例では６つの機能）の機能番号が設定される。

図３に示すように、階層定義テーブル（作成中）２１は、例えば上記図２に示すような複数の機能が階層構造となっているソフトウェア構造に従って、呼び出し元となる任意の機能（呼び出し元３６）と、“呼び出し先となる任意の各機能の各関数種別／変数種別”（呼び出し先３５）との組み合わせ（ペア）が、構築されている。そして、更に、後述するようにアクセス違反例外登録ファイル（登録）２７を利用することで、各ペア毎の違反の有無（図示の‘０’や‘１’）や違反許容数が自動的に登録されることで、後述する図４の階層定義テーブル（登録）２２が得られることになる。

尚、上記違反の有無（図示の‘０’や‘１’）や違反許容数の登録は、自動的に限らず、例えばユーザが手作業で任意に設定するものであってもよいが、その場合には当然、ユーザの手間の削減効果が少なくなる。

図３に示す階層定義テーブル（作成中）２１における図示の機能名３１、機能番号３３、機能コード３４は、何れも上記“呼び出し先となる任意の各機能の各関数種別／変数種別”における「任意の機能」を示すものであり、従って必ずしも３つとも必要なわけではない。また、階層番号（レイヤ）３２は、上記「任意の機能」が属する階層（上記３階層の何れか）を示す番号である。

呼び出し先３５は、上記各「任意の機能」毎に、その機能における上記４項目（２種類の関数種別、２種類の変数種別；ＡＰＩ（関数）、ローカル関数、グローバル変数、ローカル変数）に分類されている。このような階層・機能毎の４項目毎に、呼び出し元による呼び出し先に対する機能間でのアクセス違反があるか否か等を、階層定義テーブル（登録）２２は示していることになる。

尚、機能名３１は、その機能の名称（予め決められて登録されている）である。機能コード３４（ＳＣＩ、ＳＹＳ等）は、その機能の識別コード（予め決められて登録されている）である。機能コード３４は、プログラムソース２８による複数の機能をグループ化するためのコードであるとも言える。また、機能番号３３は、その機能の階層と当該階層内での通番から成るものである。

また、階層番号（レイヤ）３２と階層番号（レイヤ）３２は、階層に係るデータであると言える。そして、必ずしも両方必要なわけではなく、何れか一方のみであってもよい。
また、尚、本例においては機能コード３４がその機能に係わるプログラムソースファイル名や各関数／変数の名称に用いられることになっているものとする。

ここで、上記違反の有無や違反許容数の登録内容は、例えば数値等であってもよいし、後述するＡ，Ｂ，Ｃ，Ｄ等のような記号であってもよい。
図４には、数値が入力される例を示しており、数値は例えば上記違反有無を示す‘０’と‘１’であり、ここでは‘０’が“違反無し”、‘１’が“違反あり”を意味するものであるが、この例に限らない。例えば、設定値が０，１，２、・・・ｎ（ｎ；任意の整数）であり、これらの設定値は、例えば階層違反の有無や違反の許容数（「階層違反の有無や許容情報（許容登録数というものとする）」と呼ぶ場合もあるものとする）を示しており、例えば下記のように定義されるものであってもよい。
『 ０：異常として検出しない。

１：違反が１個以上存在する場合、異常として検出する。
２：違反が２個以上存在する場合、異常として検出する。
３：違反が３個以上存在する場合、異常として検出する。

・
・
・
ｎ:違反がｎ個以上存在する場合、異常として検出する。 』
例えば、過去に作成されたプログラム（レガシー資産）に基づいて作成されたプログラムの場合、違反であることが分かっていても修正困難である箇所が存在する場合がある。よって、レガシー資産において任意のペアに関して違反が２個存在すると分かっているならば、違反２件は必ず生じるのでこれは除外して考えるものとして‘３’を設定することになる（つまり、違反が３個以上存在する場合（実質的に新たな違反が１個以上存在する場合に）、新たな違反の分だけをカウントする）。

あるいは、上記のように、上記数値の代わりにＡ，Ｂ，Ｃ，Ｄ等の記号等を用いても良い。これについては特に図示しないが、例えば空白の場合には“違反なし”、下記の何らかの記号がある場合には“違反あり”であってその違反の意味は下記の通りであるものとする。

Ａ：階層を越えてＡＰＩ（外部）関数を呼び出した。
Ｂ：外部に公開されていないローカル関数をアクセスした。
Ｃ：階層を越えてグローバル（外部アクセス用）変数を呼び出した。

Ｄ：外部に公開されていないローカル変数をアクセスした。
更に、これらＡ〜Ｄだけでなく更に数値を設定してもよい。設定する値は、例えば下記の通り、違反の許容範囲（許容数）を示している。
『 ０：異常として検出しない。

１：違反が１個以上存在する場合、異常として検出する。
２：違反が２個以上存在する場合、異常として検出する。
・
・
・
ｎ:ｎ個以上存在する場合、異常として検出する。』
尚、上記のことは下記のように表現することもできる。

０：エラーを検出しない。
１：エラーを検出する。（許容するエラーなし）
２以上：エラーの許容数＋１
なお、Ｂ，Ｄは、機能内で複数のプログラムソースファイルが分かれている場合は、機能間でのやり取りに使用する変数が存在するために、他の機能からアクセスできてしまう関数や変数、また、プログラムソースファイル内であれば、そこでしか使用できない関数や変数の設定ができるが、その宣言がされていない場合にアクセスできてしまうために、他の機能が使われることを想定している。

尚、図４に示す階層定義テーブル（登録）２２の設定例は、例えば下記のルールに応じたものである。
第一階層が最下位階層、第三階層が最上位階層である。

基本的には、グローバルな変数／関数であっても、１階層下の階層への呼び出しは出来るが、２階層下の階層や上位の階層への呼び出しは出来ない。尚、同一階層への呼び出しは当然出来るのであり、これについては逐一述べない場合もある。

よって、第一階層は、上位階層から呼ばれるが、上位階層を呼び出すことはできない。
第二階層は、第一階層を呼び出すが、第三階層を呼び出すことはできない。
第三階層は、第二階層を呼び出すが、基本的には第１階層は呼び出しができない。但し、特殊な機能のみ呼び出しを許可することもあるので、設定により許可された場合は、その機能のみ呼び出すことができる。例えば図４に示す例では、呼び出し元が“機能３−１”で呼び出し先が機能１−２のＡＰＩ関数である場合には、上記ルールでは呼び出し不可（よって‘１’が設定されるはず）であるが、開発者等の判断により図示の通り‘０’が設定されている。尚、この設定は、最初から手作業で行っても良いが、半自動で生成されたものに対して、手作業で修正するものであってもよい。

尚、階層定義テーブルを設けるのは、図４に示す例のように柔軟性を設け例外を認めることを目的としており、既存製品への適合や文字列変換などの階層を越えた共通ライブラリなどを想定している。

既存製品への適合とは、レガシー資産で構造評価を行うと多くのエラーが検出される。エラーを減らすことは困難なので、これ以上階層が壊れないように現状維持を目的として、既存のエラーの値＋１を設定することにより、既存より増えた場合に点数が１００点未満となることで、簡単に判断できるようにすることを考慮している。

図５は、アクセス違反例外登録ファイル２６、２７のフォーマット例である。
尚、上記の通り、アクセス違反例外登録ファイル（作成中）２６は作成途中、アクセス違反例外登録ファイル（登録）２７は完成済みの状態を示すので、フォーマット自体は同じである。尚、アクセス違反例外登録ファイル（登録）２７は、アクセス違反を例外的に許容するものを登録したファイルである。

図示の例のアクセス違反例外登録ファイル２６、２７は、参照元機能コード４１、ソース名４２、参照先機能コード４３、検出対象名称４４、検出種別コード４５、例外アクセス許可フラグ４６、可否判定者４７の各データ項目より成る。

すなわち、参照元と参照先の機能ペア毎に、検出種別コード４５、例外アクセス許可フラグ４６、可否判定者４７が、登録されるものである。参照元と参照先の機能ペアの情報は、例えばプログラムソース２８（プログラムファイル群）から抽出される。

参照元の情報は、参照元機能コード４１及びソース名４２である。参照元機能コード４１には、参照元の機能の機能コードが格納される。ソース名４２には、参照元の機能に対応するプログラムファイル名が格納される。

ここで、本例では、プログラムソース２８を構成する各プログラムファイルは、機能単位で作成されているものとする。つまり、１つの機能に関して１つのプログラムファイルが作成されており、更に、この機能の機能コードが、プログラムファイル名に含まれるようにしている（開発者が、そのように作成していることを前提としている）。これより、このプログラムファイル名がソース名４２に格納されると共に、このプログラムファイル名から抽出された機能コードが、参照元機能コード４１に格納されることになる。

また、参照先の情報は、参照先機能コード４３と検出対象名称４４であり、更に検出種別コード４５も加わってもよいが、後述するように検出種別コード４５は単に参照先を示すだけではない（エラー情報格納部としての役割もある）。

検出対象名称４４には上記参照元の機能からのアクセス先の変数／関数が格納される。参照先機能コード４３には上記参照元の機能からのアクセス先の機能（換言すれば上記アクセス先の変数／関数が属する機能）の機能コードが格納される。尚、例えば、検出対象名称４４に含まれる機能コードを抽出して、これを参照先機能コード４３に格納するものである。

また、検出種別コード４５には、基本的には（最初は）上記アクセス先の変数／関数の種別（検出種別；本例では、ＡＰＩ関数／ローカル関数／グローバル変数／ローカル変数の４つの種別）を示すコードが格納されるが、エラーコードが格納される（あるいはエラーコードに書き換えられる）場合もある。検出種別コード４５には、例えば、１〜４、０、−１〜−６の何れかの数値が格納されるものであり、これら各数値の意味は下記の通りである。

検出種別コード： 意味 ； 具体例
１ ： ＡＰＩ関数 ；SCI_INITIAL
２ ： ローカル関数 ；Sci_FifoSet
３ ： グローバル変数 ；g_SciExpcntlUS
４ ： ローカル変数 ；gSciSendState
０ ：判定不能（ソース名規約違反などの他のエラーにより判定できない）
−１ ：ＡＰＩ関数に係るアクセス違反
−２ ：ローカル関数に係るアクセス違反
−３ ：グローバル変数に係るアクセス違反
−４ ：ローカル変数に係るアクセス違反
−５ ：規約を満たさない関数 ；例えばDebugFuncなど
−６ ：規約を満たさない変数 ；例えばWorkArea、WORKCounterUSなど
また、上記例外アクセス許可フラグ４６には、‘０’または‘１’が設定される。その意味は下記の通りである。尚、これらの設定は、基本的にはユーザ（管理者など）が手作業で行うものである。

０：アクセス違反を許容しない。
１：アクセス違反を許容する。
例外アクセス許可フラグ４６に関して、詳しくは後述する。

また、上記可否判定者４７には、上記例外アクセス許可フラグ４６を設定したユーザ（例外アクセス許容許可者）を示す情報が格納される。責任を持たせるために、例外アクセス許可フラグ４６の設定者の氏名や社員番号等を、設定者に入力させる。

既に簡単に述べたが、図２に示すソフトウェア構造の規定は、例えば下記の通りとなる。
尚、逐一述べないが、任意の機能から他の機能の呼び出しは、詳細には既に述べた通り、任意の機能に属する関数から、他の機能に属する関数または変数の呼び出しを意味する。また、これも逐一述べないが、当然、同一機能内での呼び出し（任意の関数から同じ機能内の他の関数や変数を呼び出すこと）は、基本的に全てＯＫである（違反とはならない）。

第一階層の機能は、同一階層（第一階層）の機能または１段上の階層の機能から呼ばれる。換言すれば、第一階層の機能が、上位階層の機能を呼び出すことは違反となる。これより、呼び出し元３６が第一階層の機能（１−１または１−２）であり、呼び出し先が第二階層または第三階層の機能である場合には、図示のように“違反なし”となるペアは１つも存在しないことになる。尚、ローカル関数やローカル変数に関しては、階層等は関係なく、他の機能から呼び出すこと自体が違反となる。

第二階層の機能は、同一階層（第二階層）の機能や１段下の階層である第一階層の機能を呼び出すことはできるが、上位側の階層である第三階層の機能を呼び出すことはできない。これより、例えば第二階層の機能２−１は、同一階層の他の機能である機能２−２や、第一階層の機能１−１、１−２を呼び出すことは出来るが（勿論、ローカル関数やローカル変数は呼び出せない）、第三階層の機能３−１、３−２を呼び出すことはできない。

第三階層の機能は、１段下の階層である第二階層の機能を呼び出すことはできるが、２段下の階層である第一階層の機能の呼び出しは、基本的には出来ない。これより、例えば第三階層の機能３−１は、同一階層の他の機能である機能３−２や、第二階層の機能２−１、２−２を呼び出すことは出来るが（勿論、ローカル関数やローカル変数は呼び出せない）、第一階層の機能１−１、１−２を呼び出すことはできない。

但し、特殊な機能のみ呼び出しを許可することもあるので、開発者等の判断によって例外として特別に違反としないようにする（例外として‘０’が設定される）こともできる。図４に示す例では、呼び出し元が「機能３−１」で呼び出し先が「機能１−２のＡＰＩ関数」であるペアに対して、上記例外として‘０’が設定されている。これは、第三階層の機能３−１が、第一階層の機能１−２（そのＡＰＩ関数）を呼び出すものであるので、上記の通り基本的には違反となるが、例外として“違反なし”を意味する設定がされていることになる。

尚、上記階層定義テーブル（登録）２２等のような定義ファイルを設けるのは、上記のように柔軟性を設け例外を認めることを目的としており、既存製品への適合や文字列変換などの階層を越えた共通ライブラリなどを想定している。

尚、既存製品への適合とは、レガシー資産で構造評価を行うと多くのエラーが検出され、エラーを減らすことは困難なので、これ以上階層が壊れないようにすること(現状維持)を目的として、「“既存製品の違反件数”＋１」を設定することにより（上記設定値；違反の許容範囲）、既存製品よりも違反件数が増えた場合に評価点数が１００点未満となるように定義ファイルを設定することで、簡単に判断（評価）できるようにすることを考慮している。

図６（ａ）は、アクセス違反計数ファイル２４の具体例である。また、図６（ｂ）には、図６（ａ）に示す例のアクセス違反計数ファイル２４に基づく集計結果の具体例を示している。

まず、図６（ａ）を参照して説明する。
図６（ａ）に示すように、アクセス違反計数ファイル２４のデータ構造自体は、上記図４に示す階層定義テーブル（登録）２２のデータ構造と略同様である。すなわち、アクセス違反計数ファイル２４は、機能名５１、階層番号（レイヤ）５２、機能番号５３、機能コード５４、呼び出し先５５、呼び出し元５６から成る。これらは階層定義テーブル（登録）２２の機能名３１、階層番号（レイヤ）３２、機能番号３３、機能コード３４、呼び出し先３５、呼び出し元３６と略同様であり、ここでは特に説明しないが、各呼び出し元５６（機能単位）と各呼び出し先５５（関数種別／変数種別単位）のペアに応じた違反計数欄が設定されている。

初期状態では、全ての違反計数欄（図では２４×６＝１４４個の計数欄）には、カウント値の初期値＝‘０’が設定されている。そして、アクセス違反が検出される毎に該当する違反計数欄のカウント値が＋１インクリメントされていく。

例えば評価対象の機能のプログラムソースファイルについて、そのファイルに記述されているプログラム文について先頭行から最終行まで順次参照しながら、任意の関数が他の関数あるいは変数を呼び出す箇所を見つける毎に、そのアクセスが違反か否かを階層定義テーブル（登録）２２を参照して判定し、違反である場合には上記のようにアクセス違反計数ファイル２４の該当する違反計数欄の値を更新（＋１インクリメント）する。

ここで、以下の説明では、呼び出し先に関してはその機能を機能番号で示すものとする。つまり、例えば呼び出し先として、機能番号５３が“１−１”で呼び出し先５５が“ＡＰＩ関数”であることを、「呼び出し先が“機能１−１のＡＰＩ関数”である」等と表現するものとする。

そして、図６（ａ）の例では、例えば呼び出し元５６が機能３−１で、呼び出し先が“機能１−１のグローバル関数”である場合には、違反が３回検出されたことになる。
そして、図６（ａ）に示すアクセス違反計数ファイル２４に基づいて、呼び出し先を各関数／変数単位で集計したものが、図６（ｂ）に示す集計結果である。尚、この様な集計結果もアクセス違反計数ファイル２４の一部であると見做してよい。

図示のように、この集計結果は、呼び出し元５６の各機能毎に、それぞれ、呼び出し先に関しては上記４項目（（２種類の関数、２種類の変数；ＡＰＩ（関数）、ローカル関数、グローバル変数、ローカル変数）それぞれについての集計を行ったものである。

図６（ｂ）に示す例では、例えば呼び出し元が機能１−１である場合には、呼び出し先がＡＰＩ関数である場合の違反件数は、６つの機能全てを合計しても１件だけであったことになる。

尚、図６（ａ）において、空白となっている違反計数欄は、初期値＝‘０’のままであること（違反が１件もなかったこと）を意味するものとする。
また、例えば呼び出し元５６が機能３−１で、呼び出し先が“機能１−１のＡＰＩ関数”である場合には、違反が５回検出されたことになるが、図６（ｂ）に示す集計結果は３回となっている。これは、このペアに関しては図４に示す例では‘３’（＝違反許容数）が設定されている為に、違反２回までは許容されており、３回目以降から違反としてカウントされるためである。

図７（ａ）、（ｂ）に、動作情報定義テーブル１６に設定される情報の一例を示す。
図７（ａ）は重み付けに係わる情報であり、図７（ｂ）は足きりの閾値である。
尚、必ずしも図７（ａ）、（ｂ）の両方が必要なわけではなく、どちらか片方のみであってもよい。当然、後述する処理も、それに応じた処理となる。
（I）重み付けに関して
図７（ａ）に示す重み係数は、上記アクセス対象（呼び出し先）に係わる４つの評価項目（各関数種別／各変数種別；本例ではＡＰＩ（関数）、ローカル関数、グローバル変数、ローカル変数）それぞれについて、任意の重み係数（重み値）が登録されたものである。これは、例えば開発者等が任意に決定・設定するものである。

図７（ａ）に示す重み係数は、４つの評価項目についての相対的なアクセス違反の重要度を示している。尚、重み係数の数値は、図示の例に限らず、例えば４つの項目の合計が１００％となるような重み付けでも良い。また、重み付けを細かく行う場合には、「階層定義テーブル」に対応した機能間で個別に設定ファイルを設けても良い。

図６（ｂ）等に示す、各関数種別／各変数種別（上記４つの評価項目；ＡＰＩ（関数）、ローカル関数、グローバル変数、ローカル変数）毎の違反件数の集計結果に対して、これら重み係数をそれぞれ乗算することで、集計結果を補正する。当然、ＡＰＩ（関数）に係る集計結果に対しては、ＡＰＩ（関数）に対する重み係数（図示の例では‘１’）を乗算することになる。他の評価項目についても略同様であり、例えばローカル変数に係る集計結果に対しては、ローカル変数に対する重み係数（図示の例では‘４’）を乗算することになる。

図６（ｂ）に示す集計結果例に対して、上記図７（ａ）に示す４つの評価項目毎の重み係数によって重み付け処理を行った場合、図８（ａ）に示す重み付け後の集計結果が得られることになる。

そして、最後に、図８（ａ）に示すように、呼び出し元の各機能毎に、それぞれ、上記４つの評価項目それぞれの違反件数（重み付け後）の合計値を算出・登録する。例えば、機能２−１に関しては、１＋０＋４＋１２＝１７が、違反件数（重み付け後）の合計値となる。尚、このなかの‘１２’は、元々は‘３’であったが上記ローカル変数に対する重み係数（図示の例では‘４’）を乗算したことで、違反件数（重み付け後）＝３×４＝１２となったものである。同様に、‘４’は、元々は‘２’であったがグローバル変数に対する重み係数（＝２）を乗算したことで、違反件数（重み付け後）＝２×２＝４となったものである。

更に、これら各機能毎の違反件数（重み付け後）の合計値同士を加算して全体の総計値を求める（図示の例では、９＋０＋１７＋１４＋２５＋２７＝９２）。尚、更に図示のように４つの評価項目毎（各関数種別／変数種別毎）の違反件数（重み付け後）の合計値（１１，９，１２，６０）を求めるようにしてもよい。

尚、上記各重み係数は、４つの評価項目に対し、アクセス違反の重要度を示している。これは、４つの評価項目間での相対的な重要度を示すものと言える。本例では、重き係数の値が大きいほど重要度が高いものとなっている。従って、図示の例では、ローカル変数が最も重要度が高く、ＡＰＩ関数が最も重要度が低い。これは、換言するならば、呼び出し先がＡＰＩ関数であるアクセス違反が多くても後述する評価点数にはそれほど影響しない（さほど下がらない）が、呼び出し先がローカル変数であるアクセス違反が多いと、後述する評価点数に大きく影響する（点数が非常に低くなる）ことを意味する。

尚、重み係数の数値は、図７（ａ）に示す例に限るものではなく、例えば４つの評価項目の重み係数の合計が、１００％となるような重み付けでも良い。
また、重み付けを細かく行う場合には、「階層定義テーブル」に対応した機能間で個別に設定ファイルを設けても良い。
（II）足きりの閾値に関して
評価単位当たりの（例えば呼び出し元の各機能毎の）違反件数の上限として“足きりの閾値”を設定するようにしてもよい。この足きりの設定値は、開発者等が任意に決定してよく、図７（ｂ）に示す例では“足きりの閾値”＝１０．０となっている。以下の説明では、この一例を用いるものとするが、当然、この例に限るわけではない。

違反項目は、システム（製品）によって数が異なることが予想されるため上限が分からない。そのため、点数に差が開きすぎて、違反が多い機能があると他の機能が相対的に点数が良くなり、見過ごしやすくなるので、上限を決める“足きりの閾値”を設定できるようにしている。

点数化タスク部１２は、上記図８（ａ）に示す重み付け後の集計結果と、これに基づく上記呼び出し元の各機能毎の違反件数（重み付け後）の合計値（以下、合計点数と言う場合もある）を求めたら、この合計値と各機能毎のプログラムステップ数とを用いて、アクセス違反点数化ファイル２５を生成する。

図８（ｂ）に、アクセス違反点数化ファイル２５の一例を示す。
図示の例では、アクセス違反点数化ファイル２５には以下の項目があり、呼び出し元の各機能毎またはプログラムソース２８全体に対して、以下の各項目に応じた数値が算出・登録される。
（i）ステップ数［ＬＯＣ］
機能単位のプログラムのステップ数である。図示のように、基本的には各機能１−１〜機能３−２のプログラムステップ数は、それぞれ、異なるものであり、場合によっては大きく異なることになる。よって、上記違反件数が多いからといって単純に悪いものとは言えない（プログラムステップ数が非常に多いために、その分、違反件数も多いのかもしれない）。
（ii）単位当りの点数
ＫＬＯＣ（１０００ステップ）当たりの違反検出数である。

上記のように機能毎にステップ数が異なるため、図８（ａ）に示す重み付け後の合計点（合計点数）を、プログラムのステップ数で除算し、単位（１０００ＬＯＣ）当りの点数を算出する。

すなわち、上記合計点数と上記ステップ数［ＬＯＣ］とを用いて、下記の式により算出されるものである。
単位当りの点数＝合計点数÷（ステップ数［ＬＯＣ］／１０００）
＝{合計点数／ステップ数［ＬＯＣ］}×１０００
（iii）足きり後の点数
単位当りの点数が足きりの閾値を越える場合に、足きりの閾値を単位当たりの点数とする。よって、図示の例では、機能３−２に関する単位当りの点数（１７．７３）のみが足きりの閾値（１０．０）を越えているので、１７．７３を１０．０に補正する。他の機能についてはそのままとする。

そして、単位当りの点数を、「０〜閾値⇒０〜１００」に正規化することで足きり後の点数とする。換言すれば、上記単位当りの点数を、上記足きりの閾値（１０．０）を１００点とする点数に置き換える。尚、これは、本例では閾値が１０．０であることから、単純に、上記単位当りの点数を１０倍することで（１０．０を乗算することで）、足きり後の点数が算出できる。また、尚、機能３−２に関しては、上記足きりを行っているので、１７７．３点とはならずに、図示の通り１００点となっている。
（iv）評価点数
（３）の足きり後の点数のままでは、点数が０点の場合が、違反が無く、最も良い点数となるので、１００点を最も良い点数とするように換算したものが、評価点数である。

すなわち、評価点数＝１００−“足きり後の点数”
によって評価点数を算出する。
例えば、機能１−１の場合、足きり後の点数が３８．６点であるので、
機能１−１の評価点数＝１００−３８．６＝６１．４点
となる。

但し、この例に限るものではなく、足きり後の点数を、そのまま、評価点数としてもよい（評価の仕方が変わるだけである。すなわち、０点を最も良い点数とし、０点に近いほど評価が高いものとすることになる）。

また、全体としての評価点数を求めてよい。これは、例えば、上記プログラム全体の総違反件数（＝９２）と、プログラム全体の総ステップ数（＝３０１２１）とを用いて、上記機能毎の場合と略同様にして、まず、単位当りの点数を求め、必要に応じて足きりを行った後、評価点数へと換算する。図示の例では、単位当りの点数は３．０５であり、足きりを行う必要なく、そのまま１００点満点の点数系へと換算した後に（１０倍した後に）評価点数へと換算した結果、全体の評価点数は‘６９．５’となる。

但し、この例に限るものではなく、例えば、機能１−１から機能３−２までの６つの各機能の評価点数を加算して合計値を求め、この合計値を機能数（＝６）で除算することで、全体としての評価点数を求めるようにしてもよい。

以上のコンピュータ処理結果を用いて、例えば一例としては、上記各評価点数や全体の評価点数によって、開発者等が評価対象のプログラムの評価を行うようにしてもよい。しかしながら、例えば組込み用のプログラムの場合、図２のソフトウェア構造（階層と機能）の規定に（分かっていても）違反せざるを得ないケースが頻繁に発生するケースも有り得るので、評価点数が低いから悪いと言い切れない場合がある。

一方、プログラムを改良したりバージョンアップしたり流用する場合がある。また、この場合、最初の（ベースとなる）プログラムが古い場合も有り得る。この様な古いプログラムの場合、図２のソフトウェア構造（階層と機能）の規定など意識することなく作りこんでいる場合も少なくない。この様なプログラムに係るバージョンアップ版等のプログラムの場合、評価点数が高いことは期待できず、評価点数が少なくとも以前よりも低くならなければそれでよいと言うことが（最低でも現状維持とすることが）、現実的な評価基準となる場合が少なくない。

この様な観点から、上記評価点数を更に偏差値によって評価することが考えられる。つまり、過去の製品のデータを元に、製品毎に偏差値を出すことによって相対評価を行う。
図９に、その一例を示す。

図９は、偏差値算出処理の具体例を示す図である。
図９において、製品Ａが、今回の評価対象のプログラムであるものとし、よって図示のように点数（全体の評価点数）は６９．５点となっている。

一方、製品Ｂ〜製品Ｅは、製品Ａに関連するプログラムであって過去に作成されていたプログラム等である。これらの製品Ｂ〜製品Ｅについても、それぞれ、上記製品Ａと同様の処理によって点数（全体の評価点数）が求められている。

以上の５つの製品の点数（全体の評価点数）の平均値（図示の例では３８．７）を算出し、この平均値に基づいて図示のように各製品Ａ〜製品Ｅそれぞれの偏差値を求める。偏差値の求め方は、よく知られているので、ここでは特に説明しないが、まず上記平均値と求め、これに基づいて標準偏差を求め、以って偏差値を求まることになる。

そして、今回の評価対象の製品Ａの偏差値によって、製品Ａの評価を行う。
図示の例では製品Ａの偏差値は‘６１．９’となり、過去の製品と比べて改善していることが分かる。

図１０は、階層定義テーブルとアクセス違反例外登録ファイルの半自動作成に係る処理・作業の流れを示す図である。
また、図１１に、プログラムソース２８を構成するプログラムファイルの内容例を示す。

図１０に示すように、上記処理・作業の流れは、概略的には図示の（１）〜（６）となる。以下、これら（１）〜（６）について説明する。
（１）新規プログラムの登録
まず、任意の担当者（プログラム登録者）が、作成済みのプログラムソース２８（または、各機能の雛形プログラム）を、管理サーバ１０に登録する。管理サーバ１０の不図示の記憶装置（ハードディスク等）に、プログラムソース２８が記憶される。

尚、雛形プログラムとは、外部関数のインターフェース（API）だけを宣言したプログラムのことである。ここで、階層構造のチェックは、プログラム作成（コーディング）後に行う。しかしながら、ソフトウェアの新規開発の場合は、機能毎のプログラムが並行して作成されるので、全部作成しないとチェックできない。そのため、雛形プログラムを最初に作成して、階層定義テーブルを生成可能としておくことにより、プログラムが完成していなくても、アクセス違反を検出できるようにすることができる。

但し、以下の説明では、プログラムソース２８を用いる場合を例にするものとし、雛形プログラムについては特に言及しないが、上記の通り雛形プログラムが登録されるものであってもよく、これより当然、解析対象は雛形プログラムであってもよい。
（２）プログラム解析処理
システム全体を管理している管理者（設計者）は、例えば操作端末１を操作して、ネットワーク２を介して管理サーバ１０にアクセスして、以下に説明する様々な要求を管理サーバ１０に送って、要求に応じた処理実行させる。尚、以下の管理サーバ１０の処理の説明においては、管理者による操作端末１の操作については逐一述べない場合もあるものとする。尚、この例に限らず、管理者は管理サーバ１０を直接操作して、所望の処理を実行させるものであっても構わない。また、上記要求などに対する管理サーバ１０の各種処理実行は、基本的にはサーバメイン処理部１１の管理の元に行われ、サーバメイン処理部１１が要求に応じた処理を直接または間接的に呼び出すと共に、処理結果はサーバメイン処理部１１に返されて、サーバメイン処理部１１から操作端末１に返信されるものであるが、これについても逐一述べない場合もあるものとする。

例えば、上記要求としてプログラム解析の要求を受けたサーバメイン処理部１１は、定義生成タスク部１４等を介してプログラム解析処理（図１８など）を呼び出し、（１）で登録されたプログラムソース２８から抽出した下記のデータを、階層定義テーブル（作成中）２１とアクセス違反例外登録ファイル（作成中）２６それぞれの該当フィールドに書き込む。

尚、階層定義テーブルは、全データが登録済みの状態になるまでは（作成途中段階では）階層定義テーブル（作成中）２１として一時的に記憶しておき、全データが登録済みの状態となったら（完成したら）階層定義テーブル(登録)２２として保存するものとする。

また、例えば、データが無い状態（初期状態；デフォルト）の階層定義テーブル（換言すれば、“階層定義テーブルの雛形”）が、予め管理サーバ１０の記憶装置等に格納されており、当該“（２）プログラム解析処理”の最初に、この“階層定義テーブルの雛形”のコピーを作成して、所定の記憶領域（メモリ等における作業領域など）に格納するようにしてもよい（これを階層定義テーブル（作成中）の初期状態と見做してよい）。

これは、アクセス違反例外登録ファイル（作成中）２６についても同様であり、予め記憶されている“アクセス違反例外登録ファイルの雛形”のコピーを、初期状態のアクセス違反例外登録ファイル（作成中）２６として、当該“（２）プログラム解析処理”の最初に作成しておく。

尚、これらの例に限るものではなく、例えば所定のデータ項目名をテーブルの所定のフィールドに格納することで、上記階層定義テーブル（作成中）２１の初期状態や、アクセス違反例外登録ファイル（作成中）２６の初期状態を生成する処理等であってもよい。

そして、該当フィールドに下記のデータを書き込む処理は、これら初期状態のテーブル（作成中）２１、ファイル（作成中）２６に対して行われることになる。更に、当該“（２）プログラム解析処理”によって下記のデータが書き込まれたテーブル（作成中）２１に対して、後述する“（３）階層登録＆入力チェック”による階層番号／機能番号の入力が行われることになる。このように、階層定義テーブル（作成中）２１は、現在がどの処理の段階であるかによってそのデータ格納内容が異なることになる。これは、アクセス違反例外登録ファイル（作成中）２６も同様である。

１）階層定義テーブル（作成中）２１
・ 抽出データ ： 抽出元
・機能コード ：プログラムファイル名
・機能名 ：プログラムヘッダ
２）アクセス違反例外登録ファイル（作成中）２６
・ 抽出データ ： 抽出元
・参照元機能コード ：プログラムファイル名
・ソース名 ：プログラムファイル名
・参照先機能コード ：参照している関数名、変数名から機能コードを抽出
・検出対象名称 ：参照している関数名、変数名
・検出種別コード ：参照している関数名、変数名によって判断する。尚、ここで抽出する検出種別コードは、＞０（正の値）、あるいは−５や−６である（換言すれば、−１〜−４以外である）。
（３）階層登録＆入力チェック；
システム全体を管理している管理者（設計者など）が、操作端末１を操作して、管理サーバ１０と連携して以下のデータ登録や処理を実行させる。

１）階層番号３２、又は／及び、機能番号３３の登録
管理サーバ１０は、例えば、操作端末１からの所定の要求に応じて、階層定義テーブル（作成中）２１（上記“（２）プログラム解析処理”後の状態）を所定の記憶領域から読み出し、これを操作端末１側で表示させると共に、ユーザ（設計者など）に任意のデータを入力させる。これより、ユーザは、階層番号３２、又は／及び、機能番号３３を任意に入力する。

尚、階層番号３２と機能番号３３の両方を入力すると、機能番号３３は階層番号３２を含むので矛盾が生じる場合があるので、入力時にどちらか一方しか入力できないようにしても良い。勿論、両方とも入力できるようにしてもよい。更に、その場合、後述する図１９のように入力チェック処理（入力された階層番号３２と機能番号３３とが相互に整合するか否かをチェックする処理）も行うようにしてもよい。

２）管理サーバ１０に書き込む；
管理サーバ１０は、上記操作端末１側での階層番号３２／機能番号３３の入力内容を、自己が保持・管理している階層定義テーブル（作成中）２１に反映させる（テーブル２１を更新する）。例えば、後述する図１２（ａ）に示す状態から、図１２（ｂ）または図１２（ｄ）の状態へと更新する。

３）入力のチェックを行う；
サーバメイン処理部１１は、定義生成タスク部１４を介して階層登録チェック処理（図１９）を呼び出し、当該処理（例えば図１９に示す処理）を実行させる。この処理によって定義エラー（整合エラー等）の有無が判定される。また、ユーザが階層番号３２／機能番号３３の何れか一方のみを入力した場合には、他方を自動生成する。更に、レコードの自動整列等を行うものであってもよい。詳しくは後に図１９などで説明する。

４）定義エラーがあれば、上記１）〜３）の処理を繰り返し、定義エラーが無ければ、階層定義テーブル（作成中）２１を更に更新する（例えば、後述する図１２（ｃ）に示す状態へと更新する）。

図１２には、上記「（３）階層登録＆入力チェック」の設定手順の具体例を示している。以下の設定手順（１１）、（１２）について説明する。尚、以下の説明ではユーザが機能番号３３と階層番号（レイヤ）３２の何れか一方のみを入力する場合を想定している。
（１１）ユーザが機能番号を入力するケース；
図１２（ａ）に示す状態の階層定義テーブル（作成中）２１が読み出されて表示され、ユーザが手作業で図１２（ｂ）に示すように機能番号３３を入力した場合は、サーバが自動的に、機能番号３３に含まれる階層番号を階層番号（レイヤ）３２を反映すると共に、各レコードを機能番号順に整列する。これによって、図１２（ｃ）に示す状態となる。つまり、このケースではユーザが機能番号３３を入力すると、階層番号（レイヤ）３２は自動的に生成・登録されると共に、機能番号３３に基づくレコード整列が行われる。これより、階層定義テーブル（作成中）２１は図１２（ｃ）に示す状態へと更新される。

尚、機能番号３３は“階層番号−階層内の通番”の形となっているので、“−（ハイフン）”の前の番号を取得してこれを階層番号（レイヤ）３２に登録すればよい。また、上記機能番号順に整列とは、例えば、上記“階層番号−階層内の通番”に基づいて、まず階層番号が小さいもの（ここでは‘１’が最も小さい）から順に整列させ、更に階層番号が同じもの同士に関して階層内の通番が小さいもの（ここでは‘１’が最も小さい）から順に整列させるものである。
（１２）ユーザが階層番号（レイヤ）を入力するケース；
図１２（ａ）に示す状態の階層定義テーブル（作成中）２１が読み出されて表示され、ユーザが手作業で図１２（ｄ）に示すように階層番号（レイヤ）３２を入力した場合は、下記のように処理することで、階層定義テーブル（作成中）２１は、例えば図１２（ｅ）、（ｆ）に示す状態を経て、図１２（ｃ）に示す状態へと更新される。
・ユーザが階層番号（レイヤ）３２を入力した場合は、各機能のレイヤ内の位置（順番；通番）が未定なので、下記のように通番の決定やテーブル３２の各レコードの整列を行って、機能番号３３を自動生成する。

（一）各レコードを、レイヤ（階層番号３２）が小さいもの（ここでは‘１’が最も小さい）から順に整列する。
（二）各レイヤ毎に、機能コード３４の先頭文字のアルファベット順にレコードを整列する。

（三）各レコード毎に、その階層番号（レイヤ）３２とレイヤ内の順番に基づいて、機能番号３３を自動生成する。
・ユーザが各機能のレイヤ内の位置を設計時に決めていない場合は、上記（一）〜(三)で自動的に整列・生成したものを、そのまま登録する（ケースＡ）。
・ユーザが各機能のレイヤ内の位置を設計時に決めている場合には、上記のように自動的に整列したものが、自己が決めているものと異なる場合には、自己が決めていたものと合うように調整し（手作業で入力等し）、再度自動的に整列した後に登録する（ケースＢ）。尚、当然、上記のように自動的に整列したものが、自己が決めているものと同じとなっている場合には、ケースＡと同様に、上記のように自動的に整列・生成したものを、そのまま登録する。

以下、上述した（一）〜（三）の処理について、図１２に示す具体例を参照しながら更に説明する。
ユーザが例えば図１２（ｄ）に示すように階層番号３２を手作業で入力すると、上述した処理が開始される。すなわち、まず、上記（一）に従ってテーブル１２のレコードを整列することで、階層番号（レイヤ）３２が小さいもの（ここでは‘１’が最も小さい）から順に整列される。更に、レイヤ内の順番を決定・整列する。これは、階層番号（レイヤ）３２が同じレコード同士の順番を、例えば上記（二）に従って機能コード３４のアルファベット順に整列する。これらの処理を行うことで、階層定義テーブル（作成中）２１は、レコードの順番に関しては、図１２（ｄ）に示す状態から図１２（ｅ）に示す状態となる（但し、この段階では未だ機能番号３３は未登録である）。

例えば階層番号（レイヤ）３２が‘２’のレコードに関しては、機能コード３４が“ＣＯＭ”と“ＳＹＳ”であるので、図１２（ｅ）に示すように“ＣＯＭ”のレコードの方が先となる。

そして、階層番号（レイヤ）３２と階層内での順番とによって上記“階層番号−階層内の通番”の形の機能番号３３を自動的に生成・登録することができる（上記（三））。これによって、図１２（ｅ）に示す状態とすることができる。上記ケースＡの場合には、図１２（ｅ）に示す状態をそのまま階層定義テーブル（作成中）２１の更新版として保存することになる。

一方、上記ケースＢの場合であって、仮に開発者等が設計時に階層‘１’に関してはＳＣＩはＲＴＣより順番を先にすべきものと決めていた場合には、図１２（ｅ）に示す状態では順番が逆になっていることになる。よって、この場合には、ユーザが手作業で図１２（ｆ）に示すように機能番号３３を修正することで、管理サーバ１０は機能番号３３に従ってレコードを再整列する処理を行う。これによって図１２（ｃ）に示す状態となり、これが階層定義テーブル（作成中）２１の更新版として保存されることになる。

尚、ユーザ等が予めレイヤ内の通番を決めている場合は（１１）機能番号入力、決めていない場合は（１２）階層番号（レイヤ）入力を想定している。但し、決めていない場合でも順番を変更したい場合があるので、順番を手作業で入れ替えられるようにする。

尚、図１２には示していないが、上記図１２（ｃ）に示す状態となった後、更に、機能番号３３を（図示の整列順に）呼び出し先３６に格納するようにしてもよい。これによって、呼び出し先３６には、例えば図４に示すように、機能１−１〜機能３−２まで整列順に機能番号が格納されることになる。

以上、図１０に示す“（３）階層登録＆入力チェック”の処理・作業について説明した。
次に、以下、図１０に示す“（４）アクセス違反抽出＆正常を削除”の処理・作業について説明する。
（４）アクセス違反抽出＆正常を削除
システム全体を管理している管理者（設計者など）は、操作端末１を操作して、定義生成タスク部１４を介して階層違反例外検出処理（図２０）を呼び出す。この処理では、上記（３）で更新後の階層定義テーブル（作成中）２１を参照して、アクセス違反例外登録ファイル（作成中）２６における各レコードのうちアクセス違反であるアクセス（ペア）が記録されたレコードを検出し、その検出種別コード４５を書き換える（検出種別コード４５の１〜４を、アクセス違反がある場合は−１〜−４にする）。さらに、正常である（アクセス違反ではない）レコードを削除する。

図１３には、上記（４）“アクセス違反抽出＆正常を削除”処理の設定手順の具体例を示している。これは、例えば下記の（２１）、（２２）のようになる。
尚、アクセス違反例外登録ファイル（作成中）２６は、本処理の開始時には、上記（２）の処理（図１８の処理等）によって例えば図１３（ａ）に示す状態になっている場合、本処理によって図１３（ｂ）の状態を経て図１３（ｃ）の状態がアクセス違反例外登録ファイル（作成中）２６の更新版として保存されることになる。
（２１）アクセス違反を抽出
階層定義テーブル（作成中）２１を参照して、アクセス違反例外登録ファイル（作成中）２６の登録されている各レコードに記録される各アクセス（ペア）のアクセス違反の有無を判定し、アクセス違反のレコードはその検出種別コード４５をマイナスの値（−１〜−４）にする（処理フローは図２０のＳ２０１参照）。
（２２）正常を削除
検出種別コード４５が正常（＞０）であるレコードを全て削除する（処理フローは図２０のＳ２０２参照）。

以上の処理によって更新後のアクセス違反例外登録ファイル（作成中）２６は、プログラムソース２８においてアクセス違反となる関数／変数のアクセスに係る箇所が、全て抽出されて登録されたに等しい状態となる。そして、後述する（５）によって、ユーザ（開発者等）が、上記登録されたアクセス違反のなかから任意のアクセス違反（複数あってもよいし全てであってもよい）を、例外とするように指定することができる。
（５）アクセス違反例外の許可登録
システム全体を管理している管理者（設計者など）は、アクセス違反例外の許可登録を行うために、操作端末１で以下の指示操作を行うことで、管理サーバ１０のアクセス違反例外登録ファイル（作成中）２６を更新させる。尚、本処理については特にフローチャート図等は作成していない。

１）アクセス違反例外登録ファイル（作成中）２６を読み出して、操作端末１の画面上に表示させる。尚、この画面上ではファイル２６の内容を任意に編集（追加、変更、削除など）することができる。また、尚、このときのアクセス違反例外登録ファイル（作成中）２６は、上記（４）“アクセス違反抽出＆正常を削除”処理後の状態となっている（従って、検出種別コード４５が正の値（＞０）のレコードは、存在しないはずである）。

２）上記管理者は、上記画面上でファイル２６に対して、例外的なアクセス許可の可否（例外アクセス許可フラグ４６）の登録を行うと共に、この可否登録をした人物が特定できるように自己の名前（可否判定者４７）を入力する。尚、本例では、アクセス許可する場合には、例外アクセス許可フラグ４６に‘１’を設定させるものとするが、この例に限らない。

尚、可否判定者４７は、上記のように名前を直接入力しても良いが、操作端末１にログインした時のＩＤなどを自動登録するものであってもよい。また、本例以外に、判定理由等を入力させるようにしてもよい。判定理由等は、上記画面上で直接入力してもよいし、判定理由の選択項目（“システムエラー情報収集”、“障害解析用トレース情報”など）等を予め用意して選択させてもよい。

３）上記編集作業後のアクセス違反例外登録ファイル（作成中）２６を管理サーバ１０側で保存させる（ファイル２６を更新させる）。
上記のように、アクセス違反例外登録ファイル（作成中）２６に登録された各アクセス違反のなかで、管理者等の判断により例外扱い（違反としない）するものが手作業で登録される。そして、この様な例外登録済みのアクセス違反例外登録ファイル（作成中）２６を用いて、図１０に示す下記の（６）の処理を行うことで、階層定義テーブルの半自動作成が完了することになる（階層定義テーブル（登録）２２として保存する）。その後は、保存された階層定義テーブル（登録）２２を用いて、上述した点数化・評価処理が行われることになる。

以下、図１０に示す“（６）階層違反許容の登録”処理について説明する。
（６）階層違反許容の登録
システム全体を管理している管理者（設計者）は、操作端末１を操作して、定義生成タスク部１４を介して階層違反許容の登録処理（図２１）を呼び出す。この処理では、アクセス違反例外登録ファイル（作成中）２６から上記例外的にアクセス許可されたもの以外のレコード（例外アクセス許可フラグ４６＝‘０’のレコード）を全て削除して、これをアクセス違反例外登録ファイル（登録）２７として保存する。

つまり、上記処理によってアクセス違反例外登録ファイルが実質的に完成したものとなり、アクセス違反例外登録ファイル（登録）２７として保存する。
そして、アクセス違反例外登録ファイル（登録）２７を用いて、階層定義テーブル（作成中）２１における未登録部分の自動設定、すなわち「階層違反の有無や許容情報（許容登録数）」の自動設定を行うことで、階層定義テーブルを完成させる（階層定義テーブル（登録）２２として保存する）。

上記自動設定の際に、アクセス違反例外登録ファイル（登録）２７を参照することで上記“許容登録数”を求めることができる。これについては後に図２１を参照して説明する。

上記のように、本手法では、階層定義テーブルの半自動作成を実現することができるが、更に、新規に発生したアクセス違反を見過ごすことが無くなるようにできる。これは、アクセス違反例外登録ファイルを利用することで実現できる。上記のようにアクセス違反例外登録ファイルには各アクセス違反内容が登録されるので、例えばアクセス違反が１つ増加し１つ減少することでトータルのアクセス違反数は変わらない場合でも、アクセス違反の増加と減少があったことを判別できる。

尚、本特徴に関しては、今回の解析対象のプログラムソース２８は、例えばバージョンアップ版等であり、過去に作成済みのプログラムソース２８（旧バージョン等）をベースにして作成されたものであり、且つ、過去のプログラムソース２８（旧バージョン等）についても上述した処理等によってアクセス違反例外登録ファイル（前回のアクセス違反例外登録ファイルとする）が既に作成済みであるものとする。そして、今回の解析対象のプログラムソース２８についてもアクセス違反例外登録ファイル（今回のアクセス違反例外登録ファイルとする）等が作成されたら、これを前回のファイルと比較することで、アクセス違反の増加または減少があったことを判別できる。

図１４に、この様なアクセス違反判別に係る作業・処理の流れを示す。
上述したように、この様な処理によって、新規に発生したアクセス違反を見過ごすことが無くなる（保守性維持）という効果が得られる。あるいは、機能の追加／削除が正しくされているのかユーザが確認できるという効果も得られる。

以下、図１４に示す処理手順（３１）、（３２）、（３３）について説明する。
（３１）テーブル作成
今回の解析対象のプログラムソース２８に対する上記プログラム評価処理に伴って、階層定義テーブル２１または２２と、アクセス違反例外登録ファイル２６または２７を作成する。尚、これらのテーブルの作成は、上述した（２）〜（６）の処理によって実現できるので、ここでは説明を省略する。
（３２）機能コードの差分抽出
今回の処理対象プログラムについて上記（３１）の処理で作成された階層定義テーブル（作成中）２１（但し、階層定義テーブル（登録）２２であっても構わない）と、前回のプログラム評価の際に作成してあった階層定義テーブル(登録)２２との比較処理を行い、両者の機能コードの違い（差分）を検出する。例えば、比較処理のプログラム（階層定義テーブル比較処理（図２２））を呼び出し、上記差分の検出結果（機能コードの追加／削除）を格納するテーブル（階層定義テーブル（差分）２９”））を作成する。

尚、上記前回のプログラム評価とは、例えば今回の評価対象のプログラムの前のバージョン（旧バージョン）について、過去に行われたプログラム評価を意味する。このときに作成された階層定義テーブルとアクセス違反例外登録ファイルを保存しておくことで、本処理を実現できる。

上記今回と前回の階層定義テーブル同士の比較を行い、機能コードに変化があった場合には、差分のみを例えば操作端末１に表示する。これより、システム管理者等は、機能の追加／削除が正しくされているのか内容を確認することができる。そして、もし間違いあるならば、例えばプログラムソース２８の内容を修正する等の何らかの対応をとることができる。
（３３）アクセス違反の差分抽出
今回の処理対象プログラムのプログラム評価で作成されたアクセス違反例外登録ファイル(作成中)２６と、前回のプログラム評価の際に作成されていたアクセス違反例外登録ファイル(作成中)２６との比較処理（アクセス違反例外登録ファイル比較処理（図２３））を起動する。

上記比較の結果、異なる部分がある場合には、その部分を抽出して表示する。その際、抽出した“異なる部分”（相違点）を格納するテーブル（アクセス違反例外登録ファイル（差分）２９’）を作成して、これに基づいて操作端末１への表示等を行うようにしてもよい。

この様にすることで、システム管理者等が、アクセス違反の増加／減少を個別に認識でき、以って新規に発生したアクセス違反を見過ごすことが無くなる。先願（特願２０１１−２８１５８４号）では、例えば、アクセス違反が１つ増加して１つ減少した場合には、トータルではプラマイゼロとなり、アクセス違反の新規発生を判別できないことが有り得る。尚、アクセス違反の新規発生は、例えば後述する通知を表示する等してユーザが通知内容を参照することで、ユーザが判断するものとするが、この例に限らない。

ここで、上記比較処理に用いる前回のファイル(作成中)２６と今回のファイル(作成中)２６は、作成中の状態であれば何でも良いわけでなく、図１３（ｃ）の状態であることが望ましい。よって、前回のプログラム評価の際に、図１３（ｃ）の状態のアクセス違反例外登録ファイル(作成中)２６を保存しておく必要がある。また、当該処理は、今回のプログラム評価の際に、アクセス違反例外登録ファイル(作成中)２６が図１３（ｃ）の状態になったときに実行することが望ましい。これによって、管理者等は、上記比較処理の結果（任意のアクセス違反の追加など）を参考にしながら、図１３（ｄ）に示すフラグ４６の設定等を行うことができ、より適切な設定が行われることが期待できる。

上述した各種処理について、以下、図１５以降の各図面（特にフローチャート図）を参照して更に詳細に説明する。
図１５は、サーバメイン処理部１１のフローチャート図である。

サーバメイン処理部１１は、ネットワーク２経由で操作端末１から送信されてくる下記の何れかの要求に従って、下記の当該要求に対応するタスクを呼び出し、実行完了を待ち、実行完了したら処理結果を操作端末１に通知する。尚、これらの要求は、例えば上記管理者等による任意の操作に応じて、操作端末１が生成・送信するものであるが、この例に限らない。
・点数化要求 ：“点数化タスク１２”
・定義設定要求 ：“定義アクセスタスク１３”
・定義生成要求 ：“定義生成タスク１４”
すなわち、サーバメイン処理部１１は、操作端末１からの任意の要求待ち状態で（ステップＳ１１）任意の要求を受信したら、当該要求が点数化要求である場合には（ステップＳ１２，ＹＥＳ）、点数化タスク部１２を起動し（ステップＳ１５）、点数化タスク部１２の処理完了を待ち（ステップＳ１６）、処理完了したら処理結果を操作端末１に返信する。

尚、点数化タスク部１２の処理フローチャート図は、図２４に示し、後に説明する。
また、受信した要求が、テーブル／ファイル等に対するアクセス（リード／ライト）に係る要求（まとめて、定義設定要求というものとする）である場合には（ステップＳ１３，ＹＥＳ）、定義アクセスタスク部１３を起動し（ステップＳ１７）、定義アクセスタスク部１３の処理完了を待ち（ステップＳ１８）、処理完了したら処理結果を操作端末１に返信する。

また、受信した要求が、上記テーブル／ファイル等に対するアクセス（リード／ライト）以外の何らかの処理の要求（特に、上記テーブル／ファイルの自動編集／チェック等に係る処理；まとめて、定義生成要求というものとする）である場合には（ステップＳ１４，ＹＥＳ）、定義生成タスク部１４を起動して（ステップＳ１９）、要求された処理の呼び出しと実行を行わせる。そして、定義生成タスク部１４の処理完了を待ち（ステップＳ２０）、処理完了したら処理結果を操作端末１に返信する。

尚、例えば、各要求のコマンドには、その要求が上記点数化要求、定義設定要求、定義生成要求の何れに分類される要求であるのかを示す何らかの識別情報が含まれており、サーバメイン処理部１１は、この識別情報を参照することで、上記ステップＳ１２、Ｓ１３、Ｓ１４の判定処理を行うものであるが、この例に限るわけではない。

図１６は、定義アクセスタスク部１３の処理フローチャート図である。
本処理では、受信した上記要求（コマンド）に基づいて、定義内容（例えば、リード／ライト対象のデータの種類やファイル名やテーブル名など）を判定し、この定義内容に該当するテーブル／ファイルにアクセス（読み書き）する処理を行うものである。

すなわち、まず、上記定義内容を判別する（ステップＳ３１）ことで、定義内容に該当するテーブル／ファイルにアクセスする。
例えば、定義内容が“階層定義テーブル”であれば、階層定義テーブル（２１ｏｒ２２）にアクセスする（ステップＳ３２）。例えば、定義内容が“重み計数”や“足きりの閾値”であれば、動作情報定義テーブル２３にアクセスする（ステップＳ３３）。尚、ここでは、これらの判定のために必要な情報（特に説明しない）が、予め記憶されているものとするが、この例に限らない。

上記の例以外にも、定義内容に応じて、“評価対象製品のプログラム”にアクセスする場合や（ステップＳ３４）、アクセス違反例外登録ファイル（２６ｏｒ２７）にアクセスする場合（ステップＳ３５）等があるが、アクセス先が不明であれば要求エラーを操作端末１へ返信する（ステップＳ３６）。

また、リード要求である場合には（ステップＳ３７，ＹＥＳ）、上記該当するアクセス先から読み出したデータを操作端末１へ返信する（ステップＳ３８）。ライト要求である場合には（ステップＳ３７，ＮＯ）、上記該当するアクセス先に対する処理結果（書込みの成功／不成功等）を操作端末１へ返信する（ステップＳ３９）。

尚、例えば、階層定義テーブル（作成中）２１やアクセス違反例外登録ファイル（作成中）２６に対して、管理者等が上述した任意の情報（例えば階層番号（レイヤ）３２、機能番号３３、例外アクセス許可フラグ４６、可否判定者４７等）を入力して更新させる際には、図１６の処理が行われることになる。

図１７は、定義生成タスク部１４の処理フローチャート図である。
構造評価用のテーブルやファイルを作成するために、操作端末１側から管理サーバ１０側に対して要求を行なう場合の処理であり、本実施例では、管理サーバ１０側で実行しているが、操作端末１側で処理してもかまわない。

本処理では、受信した要求の種類を判別し（ステップＳ４１）、それに応じた処理（プログラム）を呼び出す。呼び出す処理（プログラム）には、例えば下記のものがある。尚、判別方法は既存技術であり特に述べないが、例えば要求（コマンド）には判別に必要な情報（識別コード等）が含まれているものである。勿論、この例に限らない。
・プログラム解析処理（ステップＳ４２；例えば図１８の処理を実行するプログラム）
・階層登録チェック処理（ステップＳ４３；例えば図１９の処理を実行するプログラム）
・階層違反例外検出処理（ステップＳ４４；例えば図２０の処理を実行するプログラム）
・階層違反許容の登録処理（ステップＳ４５；例えば図２１の処理を実行するプログラム）
・階層定義テーブル比較処理（ステップＳ４６；例えば図２２の処理を実行するプログラム）
・アクセス違反例外登録ファイル比較処理（ステップＳ４７；例えば図２３の処理を実行するプログラム）
そして、上記何れかの処理を実行完了したら、処理完了をサーバメイン処理部１１に通知する（ステップＳ４９）。

尚、未定義の要求であれば要求エラーを操作端末１へ返信する（ステップＳ４８）。
以下、上記ステップＳ４２〜Ｓ４７の各処理について、図１８〜図２３のフローチャート図を参照して説明する。

図１８（ａ）は、“プログラム解析処理”のフローチャート図である。
図１８（ｂ）は、ステップＳ６１の“検出種別コードの作成処理”の詳細フローチャート図である。

図示の例では、プログラムのファイル名とプログラムコードから、階層定義テーブル（作成中）２１とアクセス違反例外登録ファイル（作成中）２６を、以下の手順で作成する（尚、（作成中）２１，２６とは作成途中の状態を意味し（換言すれば、未完成の状態を意味し）、完成すると（登録）２２，２７として保存されることになる。よって、上記「以下の手順で作成する」と言っても、作成完了を意味するわけではない（未だ作成途中の状態となっている）。

まず、の階層定義テーブル２１（作成中）とアクセス違反例外登録ファイル（作成中）２６のデフォルト版を、新規に作成する（ステップＳ５１）。
尚、例えば、階層定義テーブル２１（作成中）とアクセス違反例外登録ファイル（作成中）２６の雛形（各データ項目はあるが、データは一切無い状態）が、予め記憶されており、上記ステップＳ５１の処理は、これら各テーブルをコピーすると共に、解析対象のプログラムファイル名に基づくテーブル識別番号（または名称）を生成・付与するものである。これによって、解析対象のプログラムソース２８に応じた階層定義テーブル２１（作成中）とアクセス違反例外登録ファイル（作成中）２６のデフォルト版（初期状態）が、新規に作成されることになる。

上記のように、解析対象のプログラムソース２８（プログラムファイル群等）に応じたテーブル（作成中）２１，ファイル（作成中）２６のデフォルト版を生成したら、各プログラムファイル毎に下記の処理を繰り返し実行する（ステップＳ５２−Ｓ５２’間のループ処理）。

すなわち、まず、解析対象のプログラムファイルに関して、そのファイル名から機能コードを抽出し、これを階層定義テーブル（作成中）２１の機能コード３４のフィールドに格納する（ステップＳ５３）。尚、本例では、当然、ファイル名に機能コードが含まれる規定となっている場合を前提としている。

また、プログラムヘッダから機能名を抽出し、これを階層定義テーブル（作成中）２１の機能名３１のフィールドに格納する（ステップＳ５４）。これは、例えば、プログラムヘッダにおいて、機能名であることを示すキーワードから抽出する。キーワードは、図１１に示す例では、「@brief」である。「機能名 ： ｘｘｘｘ」などを予め規約として決めておき、これに従った抽出処理を開発者等が予め作成することで本処理は実現できる。

そして、プログラム本文の全行について、各行毎に下記の解析処理を行う（ステップＳ５５−Ｓ５５’間のループ処理）。
すなわち、まず、参照先(アクセス先)の変数／関数が、機能内共通（ローカル）の変数／関数、又は、グローバルな変数／関数であるか否か判定する（ステップＳ５６）。これは、例えば後述する図１８（ｂ）の処理説明で示す各種関数／変数の判定方法により、何れかに該当する場合には、ステップＳ５６の判定はＹＥＳであるものとする。

参照先（呼び出し先）が、機能内共通の変数／関数（ローカル変数／ローカル関数）、又は、グローバルな変数／関数（グローバル変数／ＡＰＩ関数）であり（ステップＳ５６，ＹＥＳ）、且つ、ファイル（作成中）２６に初めて登録する変数／関数（未登録（新規登録）の変数／変数）である場合には（ステップＳ５７，ＹＥＳ）、当該変数／関数へのアクセスに関して下記のアクセス違反例外登録ファイル（作成中）２６への登録処理（ステップＳ５８〜Ｓ６１）を行う。

すなわち、まず、プログラムファイル名をソース名４２に格納すると共に、このプログラムファイル名から機能コードを抽出して参照元機能コード４１に格納する（ステップＳ５８）。つまり、例えば、解析対象のプログラムファイルのファイル名をアクセス違反例外登録ファイル（作成中）２６のソース名４２に格納する。また、このファイル名に含まれる機能コードを抽出して（Ｓ５３で抽出したものを使用しても良い）、これをアクセス違反例外登録ファイル（作成中）２６の参照元機能コード４１に格納する。

尚、本説明では、プログラムソース２８を構成する各プログラムファイルは、機能単位で作成されているものとする。つまり、１つの機能に対応して１つのプログラムファイルが作成されている。従って、１つのプログラムファイルに関して、参照先（呼び出し先）は様々であっても（様々な機能、関数、変数が有り得る）、参照元（呼び出し元）の機能は１つであり、その機能コードはプログラムファイル名を参照すれば分かるようになっている。勿論、これは一例であり、この例に限るわけではない。

また、上記ステップＳ５６で得られた参照先の変数／関数の変数名／関数名から、参照先の機能コードを抽出して、これをファイル２６の参照先機能コード４３に格納する（ステップＳ５９）。また、この変数名／関数名を、検出対象名称４４に格納する（ステップＳ６０）。

更に、上記参照先の変数／関数に応じた検出種別コードを生成して、これをファイル２６の検出種別コード４５に格納する（ステップＳ６１）。
上記ステップＳ６１の詳細を、図１８（ｂ）に示す。

尚、上記プログラムファイル名や関数名／変数名に関しては、予め決められた下記の規約に従った名称が付けられるものとし、図１８（ｂ）にはこの規約例に従った処理例を示すが、この例に限るものではない。
＊各関数／変数の規約例
尚、下記の具体例は、機能コードが“ＳＣＩ”の例を示す。
（ａ）機能コードの判定
本例では、プログラムファイル名の先頭部分が、機能コードの大文字＋“_”（アンダースコア）となっているものとする。よって、この例では“_”の前の部分を機能コードと認識することになる。

例：プログラムファイル名がSCI_Driver.cの場合には、機能コードは“ＳＣＩ”
（ｂ）ＡＰＩ関数（グローバル関数）
関数名の先頭が、機能コードの大文字＋“_”（アンダースコア）
例： SCI_Initial(void)；
（ｃ）ローカル関数
関数名の先頭が、機能コードの先頭１文字が大文字で残りが小文字＋“_”（アンダースコア）
例： Sci_FifoSet(void);
（ｄ）グローバル変数
“g_”+ 機能コードの先頭１文字が大文字で残りが小文字
例：g_SciSendState;
（ｅ）ローカル変数
“g”+ 機能コードの先頭１文字が大文字で残りが小文字
例： gSciExpcntlUS;
図１８（ｂ）において、まず、関数か否かを判定する（ステップＳ７１）。これは、そのプログラム言語のルールに従って判断処理を作成しておけばよい。例えばＣ言語の場合には、仮に関数Ａを記述する場合には「Ａ（・・・）」というように後ろに必ず括弧が付くので、後ろに括弧がある場合には関数であるものと判定する。但し、この例に限らず、例えば上記（ｂ）、（ｃ）に示すＡＰＩ関数（グローバル関数）またはローカル関数の規約に該当する場合に、関数であると判定するようにしてもよい。

関数である場合であって（ステップＳ７１，ＹＥＳ）、更に、関数名の先頭部分（“_”（アンダースコア）より前の部分）が機能コードであって且つ全て大文字である場合（ステップＳ７２，ＹＥＳ）、ＡＰＩ関数であるものと判定し（ステップＳ７３）、当該判定結果に応じた検出種別コード（上記の例ではＡＰＩ関数は‘１’）を、ファイル２６の検出種別コード４５のフィールドに格納する（ステップＳ８２）。

尚、例えば、全ての機能コードが予め登録されているものとし、これを参照することで、“_”（アンダースコア）より前の部分が機能コードであるか否かを判別できる。
また、上記機能コードが全て大文字ではなく（ステップＳ７２，ＮＯ）、先頭１文字のみが大文字である場合には（ステップＳ７４，ＹＥＳ）、ローカル関数であるものと判定し（ステップＳ７５）、当該判定結果に応じた検出種別コード（上記の例ではローカル関数は‘２’）を、ファイル２６の検出種別コード４５のフィールドに格納する（ステップＳ８２）。

また、上記どちらの条件にも該当しない場合には（ステップＳ７２，Ｓ７４の両方ともＮＯ）、規約を満たさない関数であるものと判定し（ステップＳ７６）、当該判定結果に応じた検出種別コード（上記の例では規約を満たさない関数は‘−５’）を、ファイル２６の検出種別コード４５のフィールドに格納する（ステップＳ８２）。

また、関数ではない場合には（ステップＳ７１，ＮＯ）、先頭が‘ｇ_’であれば（ステップＳ７７、ＹＥＳ）グローバル変数であると判定し（ステップＳ７８）、先頭が‘g’であれば（ステップＳ７９、ＹＥＳ）ローカル変数であると判定し（ステップＳ８０）、これら判定結果に応じた検出種別コード（上記の例ではグローバル変数は‘３’、ローカル変数は‘４’）を、ファイル２６の検出種別コード４５のフィールドに格納する（ステップＳ８２）。

また、先頭が‘ｇ’でも‘g_’でもない場合には（ステップＳ７７，Ｓ７９の両方ともＮＯ）、規約を満たさない変数であるものと判定し（ステップＳ８１）、当該判定結果に応じた検出種別コード（上記の例では規約を満たさない変数は‘−６’）を、ファイル２６の検出種別コード４５のフィールドに格納する（ステップＳ８２）。

図１９は、階層登録チェック処理のフローチャート図である。
この処理では、操作端末１から要求（チェック指示）された階層定義テーブル（作成中）２１を読み出して、その機能番号／階層番号を下記のようにチェック／自動生成して、階層定義テーブル（作成中）２１を更新する。異常があれば操作端末１へ通知する。

また、尚、本例では、機能番号は、ｘｘｘ-ｙｙｙ（“ｘｘｘ“:階層番号、“−”：区切り記号、“ｙｙｙ”：階層内の通番）で構成されているものとする。
まず、上記のように階層定義テーブル（作成中）２１を読み出して（ステップＳ９１）、その全機能分（全レコード）について順次、下記の処理を実行する（ステップＳ９２−Ｓ９２’間のループ処理）。

まず、処理対象レコードにおいて機能番号３３が登録済みであるか否かを判定する（ステップＳ９３）。機能番号３３が登録済みの場合には（ステップＳ９３，ＹＥＳ）、更に階層番号（レイヤ）３２が登録済みか否かを判定する（ステップＳ９４）。

機能番号３３と階層番号（レイヤ）３２の両方が登録済みである場合には（ステップＳ９３，Ｓ９４がＹＥＳ）、機能番号３３と階層番号（レイヤ）３２とが整合しているか否かを判定し（ステップＳ９５）、整合していないならば（ステップＳ９５，ＹＥＳ）、整合エラーを操作端末１へ通知する（ステップＳ９６）。整合している場合には（ステップＳ９５，ＮＯ）、そのままとする（チェックＯＫ）。尚、機能番号は上記の例では「階層番号−階層内の通番」であるので、機能番号３３における階層番号の部分（区切り記号“−”より前の部分）が、階層番号（レイヤ）３２と一致すれば、整合していると判定する。

機能番号は、階層番号を含むので、下記の例では矛盾があることになる。
矛盾例：機能番号３３（階層番号 ― 階層内の通番）： 階層番号３２
（ ２ ― ２ ）： １(２でない)
（ ２ ― １ ）： ３(２でない)
（ １ ― １ ）： ２(１でない)
一方、機能番号のみが登録されている場合、すなわち機能番号３３は登録されているが階層番号３２は未登録である場合には（ステップＳ９３がＹＥＳでステップＳ９４がＮＯ）、機能番号３３から階層番号を抽出してこれを階層番号３２のフィールドに格納する（ステップＳ９７）。尚、上記の通り、機能番号は「階層番号−階層内の通番」であるので、階層番号の部分（−（ハイフン）より前の部分）を抽出すればよい。

また、階層番号のみが登録されている場合、すなわち階層番号３２は登録されているが機能番号３３は未登録である場合には（ステップＳ９３がＮＯでステップＳ９８がＹＥＳ）、レコードを階層番号順に整列すると共に（ステップＳ９９）、機能番号を決定して機能番号３３のフィールドに格納する（ステップＳ１００）。尚、機能番号は、上記の通り「階層番号−階層内の通番」であるので、例えば「階層番号３２−自然数」によって決定してもよい。但し、この例に限らず、例えば、階層内の通番は、機能コード３４の先頭文字のアルファベット順に決定してもよい。

上記の例のように、例えば、まず階層番号順に整列させ、更に各階層毎に、機能番号の「階層内の通番」は機能コードのアルファベット順として付与する。そして、機能番号順に整列することで、下記の例のようになる。

例：機能コード ；階層番号 ― 階層内の通番
整列前
ＳＹＳ ； ２ ― ２
ＣＯＭ ； ２ ― １
ＳＣＩ ； １ ― １
整列後
ＳＣＩ ； １ ― １
ＣＯＭ ； ２ ― １
ＳＹＳ ； ２ ― ２
尚、機能番号３３と階層番号３２の両方とも入力無しの場合には（ステップＳ９３、Ｓ９８がＮＯ）、未入力エラーを操作端末１に通知する（ステップＳ１０１）。

図２０は、階層違反例外検出処理のフローチャート図である。
図２０の処理は、階層定義テーブル（作成中）２１を参照して、作成途中のアクセス違反例外登録ファイル（作成中）２６を更新させるものである。

まず、階層定義テーブル（作成中）２１とアクセス違反例外登録ファイル（作成中）２６を読み出す（ステップＳ１１１）。これらは、上記の通り作成途中の状態であり、階層定義テーブル（作成中）２１は図１８及び図１９の処理後の状態、アクセス違反例外登録ファイル（作成中）２６は図１８の処理後の状態となっている。

そして、アクセス違反例外登録ファイル（作成中）２６の各レコード毎に順次、以下の各処理を実行する（ステップＳ１１２−Ｓ１１２’間のループ処理）。
そのレコードの検出種別コード４５を参照して、関数種別／変数種別を認識して（ステップＳ１１３）、それに応じてアクセス違反があるか否かを判定する。

上記判定処理によってアクセス違反と判定される場合とは、下記の場合である。尚、階層定義テーブル（作成中）２１を参照することで、参照元と参照先の各機能の階層を認識できる。

（ａ）ＡＰＩ関数／グローバル変数の場合；
参照元機能コード４１と参照先機能コード４３と階層定義テーブル（作成中）２１とに基づいて、参照元の階層と参照先の階層とを認識し、参照元の階層と同一階層／１階層下をアクセスしている場合が正常であるが、参照元の階層と同一階層／１階層下以外をアクセスしている場合には（参照先が参照元より上の階層、または２階層以上下（した）の階層である場合）、アクセス違反と判定される。

（ｂ）ローカル変数／ローカル関数；
他の機能がアクセスしている場合（参照元機能コード４１と参照先機能コード４３とが同一ではない場合）、アクセス違反と判定される。ローカル変数／ローカル関数は、同一機能内でのアクセスのみしか許されないからである。

上記（ａ）、（ｂ）の何れの場合も、アクセス違反であれば、アクセス例外許可登録ファイル（作成中）２６の該当する検出種別コード４５を書き換える。すなわち、下記のように書き換える。

１（ＡＰＩ関数） ⇒ −１（ＡＰＩ関数 アクセス違反）
２（ローカル関数） ⇒ −２（ローカル関数 アクセス違反）
３（グローバル変数）⇒ −３（グローバル変数 アクセス違反）
４（ローカル変数） ⇒ −４（ローカル変数 アクセス違反）
上述した処理（後述するＳ２０１の処理など）によって、アクセス違反例外登録ファイル（作成中）２６は、例えば図１３（ａ）の状態から図１３（ｂ）の状態になる。

上述した処理を、各関数種別／変数種別毎に示したものが、図示のステップＳ１１４〜Ｓ１２３（まとめてＳ２０１の処理と言う場合もあるものとする）であり、以下、これらの処理について簡単に説明する。

すなわち、まず、処理対象レコードの検出種別コード４５が‘１’（ＡＰＩ関数）である場合には、このＡＰＩ関数についてアクセス違反があるか否かを判定する（ステップＳ１１４）。これは、上記のように、このレコードの参照元機能コード４１と参照先機能コード４３と階層定義テーブル（作成中）２１とに基づいて、参照元と参照先とが同一階層である場合または参照先が参照元の１階層下である場合には、アクセス違反ではないものと判定し（ステップＳ１１４，ＮＯ）、以ってステップＳ１２２で違反なしと判定される（ステップＳ１２２，ＮＯ）。

一方、参照先が参照元より上の階層である場合または参照先が参照元より２階層以上下（した）の階層である場合には、アクセス違反であると判定し（ステップＳ１１４，ＹＥＳ）、このレコードの検出種別コード４５を‘−１’に書き換える（ステップＳ１１５、Ｓ１２３）。尚、当然、この場合はステップＳ１２２の判定はＹＥＳとなる。

また、処理対象レコードの検出種別コード４５が‘２’であった場合には、このローカル関数についてアクセス違反があるか否かを判定する（ステップＳ１１６）。これは、上記のように、このレコードの参照元機能コード４１と参照先機能コード４３とに基づいて、参照元と参照先とが同一の機能である場合には、アクセス違反ではないものと判定し（ステップＳ１１６，ＮＯ）、以ってステップＳ１２２で違反なしと判定される（ステップＳ１２２，ＮＯ）。一方、参照元機能コード４１が参照先機能コード４３と同一ではない場合には（ローカル関数が別の機能からアクセスされる場合）、アクセス違反であると判定し（ステップＳ１１６，ＹＥＳ）、このレコードの検出種別コード４５を‘−２’に書き換える（ステップＳ１１７、Ｓ１２３）。尚、当然、この場合はステップＳ１２２の判定はＹＥＳとなる。

また、処理対象レコードの検出種別コード４５が‘３’であった場合には、このグローバル変数についてアクセス違反があるか否かを判定する（ステップＳ１１８）。これは、上記のように、このレコードの参照元機能コード４１と参照先機能コード４３と階層定義テーブル（作成中）２１とに基づいて、参照元と参照先とが同一階層である場合または参照先が参照元の１階層下である場合には、アクセス違反ではないものと判定し（ステップＳ１１８，ＮＯ）、以ってステップＳ１２２で違反なしと判定される（ステップＳ１２２，ＮＯ）。一方、参照先が参照元より上の階層である場合または参照先が参照元より２階層以上下（した）の階層である場合には、アクセス違反であると判定し（ステップＳ１１８，ＹＥＳ）、このレコードの検出種別コード４５を‘−３’に書き換える（ステップＳ１１９、Ｓ１２３）。尚、当然、この場合はステップＳ１２２の判定はＹＥＳとなる。

また、処理対象レコードの検出種別コード４５が‘４’であった場合には、このローカル変数についてアクセス違反があるか否かを判定する（ステップＳ１２０）。これは、上記のように、このレコードの参照元機能コード４１と参照先機能コード４３とに基づいて、参照元と参照先とが同一の機能である場合には、違反ではないものと判定し（ステップＳ１２０，ＮＯ）、以ってステップＳ１２２で違反なしと判定される（ステップＳ１２２，ＮＯ）。

一方、参照元機能コード４１が参照先機能コード４３と同一の機能ではない場合には（ローカル変数が別の機能からアクセスされる場合）、アクセス違反であると判定し（ステップＳ１２０，ＹＥＳ）、このレコードの検出種別コード４５を‘−４’に書き換える（ステップＳ１２１、Ｓ１２３）。尚、当然、この場合はステップＳ１２２の判定はＹＥＳとなる。

そして、処理対象レコードがアクセス違反ではない場合には、当該レコード（検出種別コード＞０であるレコード）を削除する。すなわち、処理対象レコードの検出種別コード４５が正の値（＞０）である場合（換言すれば、判定不能や規約違反ではなく、且つ、上記処理によって負の値（‘−１’〜‘−４’の何れか）に書き換えられていない場合には）（ステップＳ１２４，ＹＥＳ）、このレコードをファイル２６（作成中）から削除する（ステップＳ１２５）。尚、これらの処理をまとめてＳ２０２の処理と呼ぶ場合もあるものとする。

上記Ｓ２０２の処理によって、アクセス違反例外登録ファイル（作成中）２６は、例えば上記図１３（ｂ）の状態から図１３（ｃ）の状態となる。
全て完了したら（上記ループ処理を抜けたら）、そのときの状態でアクセス違反例外登録ファイル（作成中）２６を保存する（ステップＳ１２６）。つまり、例えば図１３（ｃ）の状態で保存されることになる（ファイル２６が更新されることになる）。

そして、その後に不図示の上述した設定処理が実行されることで、上記（４）の“アクセス違反例外の許可登録”における「（２４）アクセス許可の設定」が行われる際に、例えば図１３（ｃ）の状態のアクセス違反例外登録ファイル（作成中）２６が読み出されて表示されて、例えばユーザによる任意のアクセス許可の設定作業が行われることになる。

この設定処理のフローチャート図や設定画面例は、特に図示しないが、ユーザは、表示されるアクセス違反例外登録ファイル（作成中）２６における例外アクセス許可フラグ４６と可否判定者４７に対応する欄に、任意の設定情報を入力することができる。例外アクセス許可フラグ４６については、‘０’または‘１’を設定できる。尚、既に述べた通り、これらの数値の意味は下記の通りである。

０：アクセス違反を許容しない
１：アクセス違反を許容する。
更に、ユーザは、可否判定者４７に、任意の氏名（基本的にはユーザ自身の指名）等を入力することになる。

上記ユーザ設定作業が完了したとき、アクセス違反例外登録ファイル（作成中）２６は、例えば図１３（ｄ）に示す状態となり、この状態で保存されることになる。
図２１は、“階層違反許容の登録処理”のフローチャート図である。

図２１の処理は、上記ユーザ設定作業によってアクセス例外許可の可否が入力済みのアクセス違反例外登録ファイル（作成中）２６（例えば図１３（ｄ）に示す状態）を読み出し、このファイル２６の各レコードのなかでアクセス違反であるが例外的に許容されているレコードのみを残すようにしたものを、アクセス違反例外登録ファイル（登録）２７として保存する処理である。更に、図２１の処理では、アクセス違反例外登録ファイル（登録）２７に基づいて、階層定義テーブル（作成中）２１における未登録部分の自動登録を行うことで階層定義テーブルを完成させる（階層定義テーブル（登録）２２として保存する）ものである。

尚、本説明では、アクセス違反例外登録ファイルについて、作成途中の状態をアクセス違反例外登録ファイル（作成中）２６とし、作成完了した状態をアクセス違反例外登録ファイル（登録）２７として区別しているが、この様な区別を行う必要性は特にない。これは、階層定義テーブルについても同様である。

以下、図２１の処理について説明する。
まず、アクセス違反例外登録ファイル（作成中）２６（例えば図１３（ｄ）に示す状態）を読み出す（ステップＳ１３１）。そして、当該ファイル（作成中）２６の各レコードを順次処理対象として、ステップＳ１３３〜Ｓ１３５の処理を実行する）（ステップＳ１３２−Ｓ１３２’間のループ処理）。

すなわち、処理対象レコードの例外アクセス許可フラグ４６を参照することで、その処理対象レコードについて（その参照元と参照先の組み合わせ）についてアクセス違反が許容されているか否かを判定する（ステップＳ１３３）。上記の通り、例外アクセス許可フラグ４６＝‘１’である場合、アクセス違反が許容されていることになり（ステップＳ１３３，ＹＥＳ）、ステップＳ１３４の処理を実行する。一方、例外アクセス許可フラグ４６＝‘０’である場合、アクセス違反は許容されないので（ステップＳ１３３，ＮＯ）、この処理対象レコードは削除する（ステップＳ１３５）。尚、当該ステップＳ１３５の処理は、必ずしも行わなくても構わない。削除しなくても、例えば、許容の登録が無いことを以って、後述するステップＳ１４２の判定がＮＯとなるようにすればよい。

ステップＳ１３４の処理では、全ての未処理レコードを検索して、処理対象レコードのアクセス形態と同一のアクセス形態（アクセス元の機能が同一で、且つ、アクセス先の機能及び検出種別（関数／変数種別）が同一）を有するレコードを全て抽出する。つまり、参照元機能コード４１と参照先機能コード４３及び検出種別コード４４が、処理対象レコードと同一である未処理レコードを全て抽出する。更に、抽出したレコードのなかで例外アクセス許可フラグ４６＝‘１’であるレコードの数をカウントし、このカウント値＋１を“アクセス違反の許容数”として記憶する。これは、例えば、処理対象レコードのアクセス形態（アクセス元の機能と、アクセス先の機能及び検出種別（関数／変数種別）との組み合わせ（ペア））に対応付けて、上記“アクセス違反の許容数”を登録する。

また、上記処理対象レコード及び上記抽出したレコードは、全て、処理済み扱いとする（例えば、これら各レコードに対して、処理済みを示す不図示のフラグ等を記録しておく）。よって、以後、これらのレコードは上記未処理レコードではないものと扱われるし、上記処理対象レコードにもならないものとする。

尚、上記“カウント値＋１”の＋１は、処理対象レコード自体を含めるためである。これによって、上記処理対象レコードのアクセス形態について、アクセス違反が許容されているレコードの数（処理対象レコードも含まれる）が、“アクセス違反の許容数”として登録されることになる。

ここで、例外アクセス許可フラグ４６は、上記のように管理者等が任意に決めて設定するのであるが、１つの考え方の例としては、上述したように「過去に作成されたプログラム（レガシー資産）に基づいて作成されたプログラムの場合、違反であることが分かっていても修正困難である箇所が存在する場合がある」ので、解析対象プログラムソース２８に関して、任意のアクセス違反についてこの様な修正困難である箇所が仮に２箇所あった場合には、違反箇所が３箇所以上ある場合に異常として検出するように構成することが望ましい（これについては既に述べている）。尚、この例の場合、上記“アクセス違反の許容数”は‘２’となるはずである。更に、この例の場合、後述する階層定義テーブル（作成中）２１における「階層違反の有無や許容情報（許容登録数）」の自動設定値は、‘３’となるはずである。この場合、上述した図４の説明中の定義により「違反が３個以上存在する場合、異常として検出する。」ものとなる。

尚、抽出したレコードのなかで例外アクセス許可フラグ４６＝‘０’であるレコードは全てファイル２６から削除すると共に、残りの（フラグが‘１’）のレコードは全て処理済みレコード扱いとするようにしてもよい。

上記ループ処理を抜けたら、そのときの状態のアクセス違反例外登録ファイル（作成中）２６を、アクセス違反例外登録ファイル（登録）２７として保存する（ステップＳ１３６）。

すなわち、上記処理によってアクセス違反例外登録ファイル（作成中）２６は例えば図１３（ｅ）に示す状態、すなわち例外アクセス許可フラグ４６が‘１’であるレコードのみが残っている状態となっている。つまり、アクセス違反が許容されているものだけが、アクセス違反例外登録ファイル（作成中）２６に残されている。ステップＳ１３６では、この状態のアクセス違反例外登録ファイル（作成中）２６を、アクセス違反例外登録ファイル（登録）２７として保存する。更に、上述した各アクセス形態に応じた“アクセス違反の許容数”の登録情報も、アクセス違反例外登録ファイル（登録）２７に含めて保存する。

その後、例えば上記“アクセス違反の許容数”等を参照することで、階層定義テーブル（作成中）２１における未登録部分、すなわち「階層違反の許容情報（許容登録数）」の自動設定を行うことができ、これによって階層定義テーブルを完成させる（階層定義テーブル（登録）２２として保存する）。

これは例えば、まず、階層定義テーブル（作成中）２１を読み込む（ステップＳ１３７）。これは例えば図１２（ｃ）に示す状態（作成途中）のものを読み込むことになる。
そして、呼び出し元と呼び出し先の各機能の組み合わせ（ペア）全てについて（但し、呼び出し先については更に各検出種別について）、それぞれ、ステップＳ１４０〜Ｓ１４４の処理を実行することで（ステップＳ１３８−Ｓ１３８’間のループ処理、及び、ステップＳ１３９−Ｓ１３９’間のループ処理）、これら全ての組み合わせについて「階層違反の有無や許容情報（許容登録数）」が自動的に登録される。

ステップＳ１４０〜Ｓ１４４の処理では、まず、処理対象の組み合わせ（ペア）がアクセス違反であるか否かを判定する（ステップＳ１４０）。これは、呼び出し先の検出種別に応じた判定処理となる。つまり、既に説明した手法を利用して、呼び出し先の検出種別がローカル変数またはローカル関数である場合には、呼び出し元の機能と呼び出し先の機能とが同一である場合にはアクセス違反ではないと判定し（ステップＳ１４０，ＹＥＳ）、それ以外はアクセス違反であると判定する（ステップＳ１４０，ＮＯ）。また、呼び出し先の検出種別がグローバル変数またはＡＰＩ関数である場合には、呼び出し先の機能の階層が、呼び出し元の機能の階層と同一または１つ下である場合には、アクセス違反ではないと判定し（ステップＳ１４０，ＹＥＳ）、それ以外はアクセス違反であると判定する（ステップＳ１４０，ＮＯ）。

アクセス違反ではないと判定された場合には（ステップＳ１４０，ＹＥＳ）、階層定義テーブル（作成中）２１における処理対象の組み合わせに対応する「階層違反の有無や許容情報（許容登録数）」の欄に、‘０’を設定する（ステップＳ１４１）。例えば、機能番号を用いて一例について説明するならば、呼び出し元が機能１−１で、呼び出し先が機能１−１のローカル関数であるならば、呼び出し元の機能と呼び出し先の機能とが同一であるので、このペアに関してはアクセス違反ではないと判定され、例えば図４に示すように‘０’が設定されることになる。

尚、上記「参照先」は上記「呼び出し先」と同義であり、上記「参照元」は上記「呼び出し元」と同義である。
一方、アクセス違反と判定された場合には（ステップＳ１４０，ＮＯ）、処理対象のペアについて許可の登録があるか否かを判定する（ステップＳ１４２）。これは、例えば、上記アクセス違反例外登録ファイル（登録）２７に含まれる、上記“アクセス違反の許容数”の登録情報を参照して判定する。上記のように、この登録情報は、アクセス違反が許容されるペア毎に“アクセス違反の許容数”が登録されているので、これらのペアの中に処理対象のペアがある場合には、許可の登録があると判定する（ステップＳ１４２，ＹＥＳ）。そして、この場合には、処理対象のペアに対応する上記“アクセス違反の許容数”を取得して、「“アクセス違反の許容数”＋１」を、階層定義テーブル（作成中）２１における処理対象のペアに対応する「階層違反の有無や許容情報（許容登録数）」の欄に設定する（ステップＳ１４３）。

一方、許可の登録が無いと判定された場合には（ステップＳ１４２，ＮＯ）、階層定義テーブル（作成中）２１における処理対象のペアに対応する「階層違反の有無や許容情報（許容登録数）」の欄に、‘１’を設定する（ステップＳ１４４）。

上記ループ処理を抜けたら、そのときの状態の階層定義テーブル（作成中）２１を、階層定義テーブル（登録）２２として保存する（ステップＳ１４５）。尚、このときの階層定義テーブル（作成中）２１の状態は、全ての「階層違反の有無や許容情報（許容登録数）」の欄に‘０’または‘１’あるいは‘２’以上の何れかの数値の設定が行われているはずである。つまり、階層定義テーブルが完成した状態となっているはずである。

尚、上記ステップＳ１３１〜Ｓ１３６の処理をまとめてＳ２０３の処理と呼ぶ場合もあるものとする。同様に、上記ステップＳ１３７〜Ｓ１４５の処理をまとめてＳ２０４の処理と呼ぶ場合もあるものとする。

図２２は、“階層定義テーブル比較処理”のフローチャート図である。
階層評価時に、前回のプログラム評価処理（旧バージョンのプログラム等）の際に登録された階層定義テーブル（登録）２２（前回階層定義テーブルというものとする）と、今回の評価対象プログラムについて新規作成した階層定義テーブル（登録）２２（今回階層定義テーブルというものとする）を読み込み、両者の差分情報を以下の手順で検出して通知する。

図２２の処理では、まず、上記前回階層定義テーブルと今回階層定義テーブルを読み込む（ステップＳ１５１）。そして、これら２つのテーブル同士を比較することで差分をとり、機能コードの種類に変化があるか否か（例えば、前回を基準にした場合、今回で増加または減少している機能コードがあるか否か）を判定する（ステップＳ１５２，Ｓ１５３）。

機能コードの種類に変化（増加または減少）がある場合には（ステップＳ１５３，ＹＥＳ）、例えば、変化があった機能コード（前回にはあるが今回には無い（削除の）機能コード、あるいは前回には無いが今回にはある（追加の）機能コード）を、全て、追加／削除の情報を含めて、操作端末１に通知する（ステップＳ１５４）。これは、例えば、変化があった機能コードと追加／削除の情報を格納した階層定義テーブル（差分）２９”を作成して、これを操作端末１に送信することで通知する。

一方、機能コードの種類に変化（追加または削除）が無い場合には（ステップＳ１５３，ＮＯ）、正常である旨を操作端末１に通知する（ステップＳ１５５）。
図２３は、“アクセス違反例外登録ファイル比較処理”のフローチャート図である。

図２３では、階層評価時に、前回のプログラム評価処理（旧バージョンのプログラム等）の際に登録されたアクセス違反例外登録ファイル（作成中）２６（前回アクセス違反例外登録ファイルというものとする）と、今回の評価対象プログラムについて新規作成したアクセス違反例外登録ファイル（作成中）２６（今回アクセス違反例外登録ファイルというものとする）を読み込み、違いがあることを以下の処理で検出し、通知する。

尚、既に説明したように、読み込むアクセス違反例外登録ファイル（作成中）２６は、前回も今回も例えば図１３（ｃ）の状態のものである。
まず、上記前回アクセス違反例外登録ファイルと今回アクセス違反例外登録ファイルとを読み込む（ステップＳ１６１）。そして、両者を比較して差分をとり（ステップＳ１６２）、変更があるか否か（例えば削除されたレコードまたは追加されたレコードがあるか否か）を判定する（ステップＳ１６３）。

そして、変更がある場合（両者に違いがある場合）（ステップＳ１６３，ＹＥＳ）、前回アクセス違反例外登録ファイルには存在していたが今回アクセス違反例外登録ファイルでは削除されたデータがある場合には、この部分を例えば操作端末１等に通知する（ステップＳ１６４）。

また、今回アクセス違反例外登録ファイル（作成中）で追加されているデータがある場合には、この追加部分を（追加の違反が見過ごされることが無いようにする為に；あるいは例えば、例外許可をするか、プログラムを修正するか等をユーザに判断させるために）操作端末１に通知する（ステップＳ１６５）。

一方、前回と今回とで変化がない場合は（ステップＳ１６３，ＮＯ）、正常であることを操作端末１に通知する（ステップＳ１６６）。
図２４は、点数化タスク部１２の処理フローチャート図である。

尚、ここでは、上記点数化要求には、点数化対象の製品を指定する情報が含まれているものとし、図２４の処理に係る各種情報／プログラムは、この指定製品に関する各種情報／プログラムであるものとする。

図２４（ａ）はメインフロー、図２４（ｂ）はステップＳ１７１の点数化処理の詳細フロー、図２４（ｃ）は更にステップＳ１８３の処理の詳細フローを示す。
図２４（ａ）に示すように、概略的には点数化処理を実行し（ステップＳ１７１）、正常終了した場合には（ステップＳ１７２，ＹＥＳ）算出結果をサーバメイン処理に通知し（ステップＳ１７３）、正常終了ではない場合には（ステップＳ１７２，ＮＯ）エラー内容をサーバメイン処理に通知する（ステップＳ１７４）。

以下、ステップＳ１７１の点数化処理について、図２４（ｂ）、（ｃ）を参照して説明する。
（１）処理実行可能か否かの確認
点数化タスク部１２は、まず、点数化に必要な情報があるか否かを判定する（ステップＳ１８１）。これは、例えば以下の２点を判定し、２点ともＯＫであれば点数化に必要な情報があると判定する
・階層定義テーブル（登録）２２と動作情報定義テーブル２３に定義が設定されている（但し、動作情報定義テーブル２３は必ずしも必要なものではない；必須ではない）。
・プログラムソース２８が登録済みである。

点数化タスク部１２は、点数化に必要な情報が無いと判定した場合には（ステップＳ１８１，ＮＯ）エラーとしてエラー内容をサーバメイン処理部１１に返して（ステップＳ１８９）、本処理を終了する。一方、点数化に必要な情報があると判定した場合には（ステップＳ１８１，ＹＥＳ）、ステップＳ１８２へ進み、点数化処理を実行する。
（２）機能毎にプログラムステップ数を計数・登録する。

まず、プログラムソース２８のプログラムステップ数を計数して（例えば各機能毎に計数して）、その結果をアクセス違反点数化ファイル２５に登録する（ステップＳ１８２）。尚、アクセス違反点数化ファイル２５には、少なくとも評価点数算出処理の実行前には、各機能毎のステップ数（ＬＯＣ）が記憶されている必要がある。

ここで、プログラムソース２８は、複数のプログラムソースファイルより構成される。各プログラムソースファイルのファイル名は、例えば開発者等が予め決められた所定のルールに従って付与している。これは、例えば、ファイル名を参照すれば、どの機能に対応するプログラムソースファイルであるのかを判別できるようになっている。

すなわち、プログラムソース２８を構成する各プログラムソースファイルと各機能との対応関係は、本例では下記のａ）の方法を想定して“階層定義テーブル”等に機能コードを登録している。但し、この例に限らず、他の方法（例えば下記の、ｂ）,c）の方法）を行っても良い。

a)ファイル名に機能コードをつける。更に階層を示す情報も付加してもよい。
一例としては例えば、“xxxx_yyyy_abcdef.c”（xxxx:階層、yyyy:機能コード）のように、プログラムの命名規約を決定しておき、プログラムソース２８を構成する各プログラムソースファイルのファイル名は、この命名規約に従って付与させるようにする。尚、規約に反するプログラムはエラーとするチェック機能を別途備えるようにしてもよい。

これより、例えばプログラムソース２８を構成する各プログラムソースファイル毎に、そのファイルのプログラムのステップ数（行数等）をカウントすると共に、そのファイルのファイル名から上記機能コードを取得して、これらに基づいてアクセス違反点数化ファイル２５に各機能毎（機能コード毎）のステップ数を登録することができる。

尚、１つの機能に対して複数のプログラムソースファイルが存在する場合には、上記ファイル名に含まれる機能コードが同一である複数のプログラムソースファイルについてまとめて上記プログラム・ステップ数のカウント処理を行って、これらの合計値をアクセス違反点数化ファイル２５に登録することになる。

また、階層定義テーブル（登録）２２を参照する際や、アクセス違反計数ファイル２４の該当計数欄を見つける際にも、上記ファイル名を参照してその階層や機能コードを取得することになる。

b)ディレクトリ指定
ディレクトリ構造をソフトウェア階層と同じにして、その中に各プログラムソースファイルを格納する（例えばＳＣＩというディレクトリに、機能コードがＳＣＩである機能に係る全てのプログラムソースファイルを格納する。

c)定義ファイルに登録
階層と機能とプログラムソースファイル名との対応関係を、定義ファイル（不図示の定義マクロ、又は、定義テーブル等）に登録する。すなわち、この定義ファイルを参照すれば、どのプログラムソースファイルが、どの階層のどの機能に対応するものであるか判別できるようにする。
（３）アクセス違反を計数する。

評価対象の製品のプログラムソース２８について、階層定義テーブル（登録）２２を参照してアクセス違反を判定して、アクセス違反の数をアクセス違反計数ファイル２４上で計数する（ステップＳ１８３）。これは、例えば上記４つの評価項目を対象とするものであるが、この例に限らない。

これは、上記の通り、階層定義テーブル（登録）２２には、呼び出し元３６（機能単位）と呼び出し先３５（各機能毎の関数種別／変数種別単位）のペア毎に、例えば“違反なし”か“違反あり”が登録されている（あるいは、更に、違反の許容数が登録されている）。一方、プログラムソース２８に係わる機能コードや関数／変数の種類（種別）は、例えば上述した方法によって識別可能である。これより、プログラムソース２８に関して呼び出し元の機能と呼び出し先の機能及び関数種別／変数種別とを認識し、階層定義テーブル（登録）２２を参照することで、違反の有無等を判別できる。尚、ステップＳ１８３の処理の詳細については、後に図２４（ｃ）に示す詳細フローを参照して説明するものとする。
（４）違反の計数結果に対して重み付けを行う。

動作情報定義テーブル２３に含まれる上記４つの評価項目に対する重み係数を用いて、上記ステップＳ１８３によって得られた違反件数集計結果を補正することで、重み付け後の集計結果を求める（ステップＳ１８４）。つまり、例えば、アクセス違反計数ファイル２４の集計値に、動作情報定義テーブル２３の重み計数値を乗算した結果を、不図示の重み付け後の集計結果ファイルに登録する。
（５）アクセス違反を点数化する。

例えば上述した評価点数を算出する（ステップＳ１８５）。
評価点数の算出方法については、既に一例を用いて説明済みであるので、ここでは以下に簡単に説明するのみとする。

すなわち、上記“重み付け後の集計結果”を、プログラムステップ数（ＫＬＯＣ）で除算して更に所定単位（例えば１０００）を乗算することで、上記”単位当たりの点数“を求め、これを動作情報定義テーブル２３の上記“足きりの閾値”で必要に応じて足きりした後に“足きりの閾値”を１００点満点とする点数系に換算することで上記“足きり後の点数”を求め、「１００−“足きり後の点数”」を上記“評価点数”とする。

上記“評価点数”としては、（呼び出し元となる）各機能毎の評価点数や、プログラムソース２８全体としての評価点数等を求めることになる。
（６）偏差値を算出する
上記算出した評価点数を記憶すると共に、過去に他の製品等に関して上記“評価点数”が算出されて記憶されていた場合には、当該評価点数が記憶（登録）されている製品数が、予め任意に設定されている所定値以上（本例では５以上）であれば（ステップＳ１８６，ＹＥＳ）、偏差値を算出する（ステップＳ１８７）。

尚、偏差値の算出処理については、既に説明済みであるので、ここでは説明しない。
尚、評価点数算出・登録済みの製品数が所定値未満（５未満）である場合には（ステップＳ１８６，ＮＯ）、そのままステップＳ１８８の処理へ移行する。
（７）処理結果をサーバメイン処理に返す。

上記算出結果すなわち評価点数や偏差値等を、サーバメイン処理部１１に返す（ステップＳ１８８）。
プログラム開発担当者等は、任意のプログラムを作成すると、上記管理サーバ１０によってそのプログラム構造を解析・点数化させることで、その評価点数、偏差値等によって、プログラムがソフトウェア構造設計通りに作成できたか、あるいは少なくとも過去の他製品に比べてレベルダウンしていないこと等を確認することができる。これは、数値化・点数化が行われたことで、客観的な分かり易い評価基準が示されるので、容易に的確な評価・判断を行うことができることになる。そして、たとえば、もし、レベルダウンしていると判断されるならば、開発担当者等は、プログラムの見直しを行うことになる。

尚、上記ソフトウェア構造設計とは、既に述べた通り、例えば、複数の機能より成るソフトウェアにおける機能間のアクセスに係る制限があるソフトウェア構造設計である。これに、更に、階層構造に係る制限も加わってもよい。階層構造に係る制限については、例えば一例を図２等で説明したように、複数の機能が階層化されたソフトウェア構造において、少なくとも相対的に下位側の機能から上位側の機能を呼び出すことは違反である、等の制限がある。これに加えて更に、上位側の機能から下位側の機能を呼び出す場合であっても、２段以上（いじょう）下（した）の層の機能を呼び出すことは違反となるようにしてもよい。

また、管理者は評価点数が基準値（過去の製品（変更前の製品等）の評価点数）以上であることを確認するだけで、開発初期の構造が維持できる。さらに、偏差値を算出することにより、過去の製品と比較して向上を図れるようにする。点数化することで客観的に品質を評価できる。

別の側面から言えば、本システムにより、以下の効果が得られるものといえる。
・プログラムそのものを見なくても、ソフトウェア構造を確認できる（開発効率化）。
・ソフトウェア構造が変わらないので、メンテナンス性を維持できる（保守性維持）。

過去の製品の評価点数と比べて、点数が下がらない場合には、ソフトウェア構造が変わらない（維持できている）（品質が下がらない）と判断できる。
尚、上記のようなソフトウェア構造設計の制限は、完全に守らなくても（多少違反があっても）、直ちにソフトウェアが正常に動作しないものとなるというものではない。例えば、一応は正常に動作するが、上記制限がある程度以上守られている（少なくとも過去よりは悪くなっていない）ことを確認したい場合（品質が下がらないことを確認したい場合）等に、本システムが有効利用できることになる。

以下、図２４（ｃ）を参照して、上記ステップＳ１８３の処理の詳細例について説明する。尚、この例では、機能や関数種別／変数種別（４つの評価項目等）を、名称（プログラムソースファイル名、関数名、変数名）によって識別可能とした場合を示すが、この例に限らない。

ここでは、一例として、機能やプログラムソースファイル名や関数／変数の名称が、以下のルールに従って決められているものとする。また、このルールに基づくプログラム例を図２５に示す。

尚、ここでは機能コードが“ＳＣＩ”である機能の例を示すが、勿論、この例に限らない。
＊機能コードの判別
各プログラムソースファイルのファイル名の一部に、それが関係する機能の機能コードが含まれるようにしている。すなわち、例えば、予め決めたルールに従って、各プログラムソースファイル名の先頭が「機能コードを示す大文字＋“_”（アンダースコア）」となっている。尚、ここでは、更に、機能コードは３文字であるという規定もあるものとする。

具体例： プログラムソースファイル名＝SCI_Driver.c
よって、上記の例では、機能コード（機能名と見做してもよい）は“ＳＣＩ”であると判定する。尚、必ずしも１つの機能に１つのプログラムソースファイルのみが対応するとは限らない。１つの機能に複数のプログラムソースファイルが対応しても構わない。換言すれば、機能コードは、複数のプログラムソースファイルをグループ化するもの（複数のプログラムソースファイルから構成される機能に対して割当てられるもの）であってもよい。上記の例で言えば上記“SCI_Driver.c”以外にもファイル名の先頭３文字が“ＳＣＩ”であるプログラムソースファイルが存在するかもしれないことになる。
＊ＡＰＩ関数の判別
ＡＰＩ関数である関数は、全て、その関数名の先頭が「機能コードの大文字＋“_”（アンダースコア）」となっている。

具体例： SCI_Initial(void)；
尚、図２５には上記具体例を用いたプログラム例が示してある。
＊ローカル関数の判別
ローカル関数である関数は、全て、その関数名の先頭が「機能コードの先頭１文字が大文字で残りが小文字＋“_”（アンダースコア）」となっている。

具体例： Sci_FifoSet(void);
尚、図２５には上記具体例を用いたプログラム例が示してある。
＊グローバル変数の判別
グローバル変数である変数は、全て、その変数名の先頭が「“g_”+ 機能コードの先頭１文字が大文字で残りが小文字」となっている。

具体例： g_SciSendState;
尚、図２５には上記具体例を用いたプログラム例が示してある。
＊ローカル変数の判別
ローカル変数である変数は、全て、その変数名の先頭が「“g”+ 機能コードの先頭１文字が大文字で残りが小文字」となっている。

具体例： gSciExpcntlUS;
尚、図２５には上記具体例を用いたプログラム例が示してある。
尚、上記の例では、機能コードに関するルールとして「先頭にはｇは使わない」を追加することが望ましい。

上記のように、本手法では、プログラムソース文における関数／変数の名称には、その関数／変数の属する機能を示す情報と、その関数／変数の関数種別／変数種別を示す情報とが含まれている。これらの情報は、例えば上記一例のような所定のルールに従ったものである。このように、本手法では、関数／変数の名称を参照することで、その関数／変数の属する機能や、その関数／変数の関数種別／変数種別等を判別できる。

このように、本例では、名称によって機能及び関数種別／変数種別等を区別できるため、static変数等のようなソース内でのみ区別可能なものとは異なり、例えばある機能のグローバル変数と他の機能のグローバル変数とを区別することや、ある機能の変数と、これと同一の変数名の他の機能の変数とを区別できる。

以下、上記一例を用いながら、図２４（ｃ）に示す詳細フローチャート図について説明する。
図２４（ｂ）において、評価対象のプログラムソース２８を構成する全てのプログラムソースファイルを、順次、解析対象として（ステップＳ１９１）、解析対象のプログラムソースファイルについてステップＳ１９２〜Ｓ１９６の解析処理を行うことを繰り返す。そして、全プログラムソースファイルについて解析処理が完了したら、ステップＳ１９７の処理を行って、本処理は終了する。

以下、まず、ステップＳ１９２〜Ｓ１９６の処理について説明する。
まず、解析対象のプログラムソースファイルのファイル名に基づいて、その機能コード（機能名）を判定する（ステップＳ１９２）。上記一例の場合、プログラムソースファイル名＝SCI_Driver.cであることから、機能コード（機能名）は“ＳＣＩ”であると判定する。また、図４に示す例では、機能コード３４が“ＳＣＩ”の機能の機能番号３３は、「機能１−１」となっている。つまり、これが、上記階層定義テーブル（登録）２２における呼び出し元３６の機能番号となる。

そして、解析対象のプログラムソースファイルについて、例えば１行目〜最終行までを順次参照して、任意の関数が任意の他の関数または変数の呼び出しを行う箇所を見つける毎に、当該呼び出し先の関数または変数の名称に基づいて、その関数種別／変数種別と呼び出し先の機能とを判別する。

すなわち、例えば、名称の先頭部分が、ｇで始まり、且つ、ｇの次が“_”（アンダースコア）である場合には、グローバル変数であると判定し、ｇの次が“_”ではない場合にはローカル変数と判定する。更に、“_”またはｇに続く３文字を抽出して、これを全て大文字にしたものを呼び出し先の機能の機能コードと認識する。

また、例えば、名称の先頭部分がｇ以外で始まる場合には、“_”（アンダースコア）を見つけて“_”より前の文字列を抽出し、抽出した文字全てが大文字である場合には、ＡＰＩ関数であると判定する。また、抽出した文字列のうち先頭の文字のみが大文字である場合には、ローカル関数であると判定する。また、何れに場合でも、抽出した文字列を全て大文字にしたものを呼び出し先の機能の機能コードと認識する。

以上の処理により、呼び出し元３６の機能番号と、呼び出し先の機能コード３４及び種別（呼び出し先３５に示す４つの評価項目の何れか；関数種別／変数種別）のペアを判別できるので、このペアに基づいて上記階層定義テーブル（登録）２２を参照して違反の有無を判定でき、更に違反であればアクセス違反計数ファイル２４の該当計数欄に計数することができる（ステップＳ１９３，Ｓ１９４，Ｓ１９５，Ｓ１９６）。尚、その際、呼び出し先が自機能である場合には、階層定義テーブル１５を参照することなく、違反なしと判定するようにしてもよい。

これより、例えば、呼び出し先が他機能のグローバル変数であれば、階層定義テーブル（登録）２２を参照して違反の有無を判定し、違反であればアクセス違反計数ファイル２４の該当計数欄に計数する（ステップＳ１９３）。

同様に、呼び出し先が他機能のローカル変数であれば、階層定義テーブル（登録）２２を参照して違反の有無を判定し、違反であればアクセス違反計数ファイル２４の該当計数欄に計数する（ステップＳ１９４）。

呼び出し先が他機能のＡＰＩ関数であれば、階層定義テーブル（登録）２２を参照して違反の有無を判定し、違反であればアクセス違反計数ファイル２４の該当計数欄に計数する（ステップＳ１９５）。

呼び出し先が他機能のローカル関数であれば、階層定義テーブル（登録）２２を参照して違反の有無を判定し、違反であればアクセス違反計数ファイル２４の該当計数欄に計数する（ステップＳ１９６）。

以上の処理を解析対象のプログラムファイルの全呼び出し処理に関して実行したら、未解析のプログラムファイルがある場合にはそれを次の解析対象として同様の処理を実行し、全てのプログラムファイルについて処理実行完了したらループを抜けてステップＳ１９７の処理へと移行する。

ステップＳ１９７では、階層定義テーブル（登録）２２の設定に従って、場合によっては、上記計数済みのアクセス違反計数ファイル２４の内容を補正する。これは既に述べたように‘０’、‘１’以外の値（例えば‘３’）が設定されている場合には、これを違反許容数等とする上述した補正を行う。

上記ステップＳ１８４では、この様な補正後の集計結果を用いて、例えば上述した重み付けを行うことになる。
尚、上記図１５〜図２４に示すフローチャートの処理は、管理サーバ１０の不図示のＣＰＵ等が、不図示の記憶装置（ハードディスク、メモリ等）に予め記憶されている所定のアプリケーションプログラムを読出し・実行することにより実現される。

尚、上述した処理例は、一例であり、この例に限るものではない。また、必ずしも上述した処理例の処理全てを実行する必要性があるとは限らない。例えば、階層定義テーブルの半自動生成は、例えば図１０に示す（２）と（３）のみとし、上記「階層違反の有無や許容情報（許容登録数）」は、ユーザが手作業で任意に設定するものであってもよい。尚、この例の場合、アクセス違反例外登録ファイル２６（２７）は、必ずしも生成しなくてもよい（つまり、図１０の（２）の処理では、階層定義テーブル（作成中）２１のみが生成されるものであってもよい）。

以上説明したように、本発明のプログラム構造評価システム等によれば、複数の機能より成るソフトウェアにおける機能間のアクセスに係る制限があるソフトウェア構造設計に従ったプログラム作成が行われたか否かについて、プログラムを解析・点数化することで容易に評価可能とすることができる。更に、この解析・点数化のために必要となる階層定義テーブルを、半自動生成することもでき、階層定義テーブルの設定作業の手間を軽減することができる。

新規に作成した製品（プログラム等）は、対応する階層定義テーブルが無いため、階層評価以前に、対応する階層定義テーブルを予め作成しなければいけない。これを手動入力してもよいが、大規模になると新規作成に非常に手間がかかる。

これに対して、本例では、上述したように階層定義テーブルを半自動作成できる。
また、上述したように、旧ソフトウェア（レガシー資産）を利用して改造等を行って新規ソフトウェアとして作成する場合もあるが、レガシー資産における違反は、違反であることが分かっていても修正することが困難な場合が少なくなく、現状維持（それ以上違反を増やさない）が出来ればよいとする場合がある。しかしながら、新規ソフトウェア作成の際に、違反の削除と追加が同時に発生すると、追加の違反が見過ごされる可能性がある。例えば、違反が１つ増えて１つ減った場合には、トータルの違反数は変化がないので、新規違反発生を見逃す可能性がある。

これに対して、本手法では、階層違反の例外情報（プログラム、関数・変数名、違反内容など）を記録し、前回の情報（旧バージョンのプログラムの際に作成されていた例外情報等）と比較することで、違反が新規に発生したものがあるか判断し、新規発生であれば、既存の許容すべきものなのかを判断することにより、新規に発生した違反を見過ごさないようにする。

上述したように、本発明では、上述した効果に加えて以下の効果が得られる。
（１）階層定義テーブルの半自動生成を実現できる。例えばユーザが階層定義や違反の許容の有無を設定するだけで、階層定義テーブル（登録）２２が自動的に作成される（開発効率化）。
（２）新規に発生したアクセス違反を見過ごすことが無くなる。（保守性維持）
尚、上述した管理サーバ１０の各種処理機能は、換言すれば、管理サーバ１０は下記の各種処理機能部（不図示）を有するものと言うこともできる。

すなわち、管理サーバ１０は、下記の違反有無情報記憶部と違反判定部と集計部と評価点数算出部と違反有無情報生成部の各種処理機能部を有するものと言うこともできる。
違反有無情報記憶部は、複数の機能より成るソフトウェアの機能間のアクセスに係る制限に従って、呼び出し元となる機能と呼び出し先となる機能の関数種別／変数種別との組み合わせである機能ペア毎に、違反の有無、または／及び、違反許容数が格納された違反有無情報を記憶する。

違反判定部は、評価対象のソフトウェアのプログラムソース文を順次参照して、任意の機能から他の機能の任意の関数／変数を呼び出す処理を検出する毎に、該呼び出し先の関数／変数の関数種別／変数種別を判別して、さらに上記違反有無情報を参照して、該呼び出しが違反か否かを判定する。

集計部は、上記違反判定部による判定結果に基づいて、上記各機能毎または／及び上記評価対象のソフトウェア全体の違反件数を集計する。
評価点数算出部は、該集計部による違反件数の集計結果に基づいて、上記評価対象のソフトウェア全体または／及びその各機能毎の評価点数を算出する。

違反有無情報生成部は、予め、上記評価対象のソフトウェアに基づいて、上記違反有無情報を生成して上記違反有無情報記憶部に記憶させる。
また、例えば、上記違反有無情報生成部は、
上記評価対象のソフトウェアから各機能に係る所定のデータ項目のデータを抽出して、これを初期状態の違反有無情報に格納するプログラム解析部と、
上記プログラム解析部の処理後の上記違反有無情報に対して、階層に係るデータ項目のデータを設定させる階層データ設定部とを有するものであってもよい。

また、例えば、上記違反有無情報は、任意の機能の識別情報である機能名または／及び機能コードと、該機能の階層を示す階層番号、または／及び、該階層番号が含まれる機能番号の各データ項目を有し、上記抽出される、各機能に係る所定のデータ項目は、上記機能名または／及び上記機能コードであり、上記設定させる、上記階層に係る任意のデータ項目は、上記階層番号または／及び上記機能番号であってもよい。

また、例えば、上記階層データ設定部は、上記階層番号と上記機能番号の両方が設定された場合には、両者が整合するか否かをチェックし、上記階層番号と上記機能番号の何れか一方が設定された場合には、該設定データに基づいて他方のデータを生成するものであってもよい。

また、例えば、上記プログラム解析部は、更に、上記評価対象のソフトウェアから、上記機能ペアを示すデータを抽出して、該機能ペアデータを初期状態のアクセス違反例外情報に記憶するものであってもよい。

また、例えば、上記違反有無情報生成部は、
上記アクセス違反例外情報を参照して、上記記憶された機能ペア毎にアクセス違反か否かを判定し、アクセス違反ではないと判定された機能ペアは上記アクセス違反例外情報から削除し、アクセス違反であると判定された機能ペアに対して違反種別を記憶するアクセス違反判別部を更に有するものであってもよい。

また、例えば、上記違反有無情報生成部は、
上記アクセス違反判別部による処理後の上記アクセス違反例外情報の上記機能ペア毎に、そのアクセス違反を許容するか否かを任意に設定させる違反許容設定部を更に有するものであってもよい。

また、例えば、 上記違反有無情報生成部は、
上記違反許容設定部による設定後の上記アクセス違反例外情報を用いて、上記階層データ設定部による設定後の上記違反有無情報に対して、当該違反有無情報における上記機能ペア毎の違反の有無または／及び違反許容数を自動的に設定する違反有無情報設定部を更に有するものであってもよい。

また、例えば、上記評価対象のソフトウェアに対応する上記アクセス違反例外情報と、該評価対象のソフトウェアに関連する別のソフトウェアに対応して生成済みであった上記アクセス違反例外情報である前回アクセス違反例外情報とを相互に比較して、相違がある場合には相違点を抽出する違反増減検出部を更に有するものであってもよい。

また、例えば、上記評価対象のソフトウェアに対応する上記違反有無情報と、該評価対象のソフトウェアに関連する別のソフトウェアに対応して生成済みであった上記違反有無情報である前回違反有無情報とを相互に比較して、登録されている機能に相違がある場合には相違点を抽出する機能変化検出部を更に有するものであってもよい。

また、例えば、他の複数のソフトウェアについてそれぞれ上記評価点数が算出済みである場合に、上記評価対象のソフトウェアの評価点数も含む該複数の評価点数に基づいて、上記評価対象のソフトウェアの評価点数について偏差値を算出する偏差値算出部を更に有するものであってもよい。

１ 操作端末
２ ネットワーク
１０ 管理サーバ
１１ サーバメイン処理部
１２ 点数化タスク部
１３ 定義アクセスタスク部
１４ 定義生成タスク部
１５ 偏差値計数ファイル
２１ 階層定義テーブル（作成中）
２２ 階層定義テーブル（登録）
２３ 動作情報定義テーブル
２４ アクセス違反計数ファイル
２５ アクセス違反点数化ファイル
２６ アクセス違反例外登録ファイル（作成中）
２７ アクセス違反例外登録ファイル（登録）
２８ プログラムソース
３１ 機能名
３２ 階層番号（レイヤ）
３３ 機能番号
３４ 機能コード
３５ 呼び出し先
３６ 呼び出し元
４１ 参照元機能コード
４２ ソース名
４３ 参照先機能コード
４４ 検出対象名称
４５ 検出種別コード
４６ 例外アクセス許可フラグ
４７ 可否判定者
５１ 機能名
５２ 階層番号（レイヤ）
５３ 機能番号
５４ 機能コード
５５ 呼び出し先
５６ 呼び出し元

Claims (20)

1. 任意のソフトウェアについて所定の評価を行うためのコンピュータシステムにおいて、
   複数の機能より成るソフトウェアの機能間のアクセスに係る制限に従って、呼び出し元となる機能と呼び出し先となる機能の関数種別／変数種別との組み合わせである機能ペア毎に、違反の有無、または／及び、違反許容数が格納された違反有無情報を記憶する違反有無情報記憶手段と、
   評価対象のソフトウェアのプログラムソース文を順次参照して、任意の機能から他の機能の任意の関数／変数を呼び出す処理を検出する毎に、該呼び出し先の関数／変数の関数種別／変数種別を判別して、さらに前記違反有無情報を参照して、該呼び出しが違反か否かを判定する違反判定手段と、
   前記違反判定手段による判定結果に基づいて、前記各機能毎または／及び前記評価対象のソフトウェア全体の違反件数を集計する集計手段と、
   該集計手段による違反件数の集計結果に基づいて、前記評価対象のソフトウェア全体または／及びその各機能毎の評価点数を算出する評価点数算出手段と、
   予め、前記評価対象のソフトウェアに基づいて、前記違反有無情報を生成して前記違反有無情報記憶手段に記憶させる違反有無情報生成手段と、
   を有することを特徴とするプログラム構造評価システム。
2. 前記違反有無情報生成手段は、
   前記評価対象のソフトウェアから各機能に係る所定のデータ項目のデータを抽出して、これを初期状態の違反有無情報に格納するプログラム解析手段と、
   前記プログラム解析手段の処理後の前記違反有無情報に対して、階層に係るデータ項目のデータを設定させる階層データ設定手段とを有する、
   ことを特徴とする請求項１記載のプログラム構造評価システム。
3. 前記違反有無情報は、任意の機能の識別情報である機能名または／及び機能コードと、該機能の階層を示す階層番号、または／及び、該階層番号が含まれる機能番号の各データ項目を有し、
   前記抽出される、各機能に係る所定のデータ項目は、前記機能名または／及び前記機能コードであり、
   前記設定させる、前記階層に係る任意のデータ項目は、前記階層番号または／及び前記機能番号であることを特徴とする請求項２記載のプログラム構造評価システム。
4. 階層データ設定手段は、
   前記階層番号と前記機能番号の両方が設定された場合には、両者が整合するか否かをチェックし、
   前記階層番号と前記機能番号の何れか一方が設定された場合には、該設定データに基づいて他方のデータを生成することを特徴とする請求項３記載のプログラム構造評価システム。
5. 前記プログラム解析手段は、更に、前記評価対象のソフトウェアから、前記機能ペアを示すデータを抽出して、該機能ペアデータを初期状態のアクセス違反例外情報に記憶することを特徴とする請求項２記載のプログラム構造評価システム。
6. 前記違反有無情報生成手段は、
   前記アクセス違反例外情報を参照して、前記記憶された機能ペア毎にアクセス違反か否かを判定し、アクセス違反ではないと判定された機能ペアは前記アクセス違反例外情報から削除し、アクセス違反であると判定された機能ペアに対して違反種別を記憶するアクセス違反判別手段を更に有することを特徴とする請求項５記載のプログラム構造評価システム。
7. 前記違反有無情報生成手段は、
   前記アクセス違反判別手段による処理後の前記アクセス違反例外情報の前記機能ペア毎に、そのアクセス違反を許容するか否かを任意に設定させる違反許容設定手段を更に有することを特徴とする請求項６記載のプログラム構造評価システム。
8. 前記違反有無情報生成手段は、
   前記違反許容設定手段による設定後の前記アクセス違反例外情報を用いて、前記階層データ設定手段による設定後の前記違反有無情報に対して、当該違反有無情報における前記機能ペア毎の違反の有無または／及び違反許容数を自動的に設定する違反有無情報設定手段を更に有することを特徴とする請求項７記載のプログラム構造評価システム。
9. 前記評価対象のソフトウェアに対応する前記アクセス違反例外情報と、該評価対象のソフトウェアに関連する別のソフトウェアに対応して生成済みであった前記アクセス違反例外情報である前回アクセス違反例外情報とを相互に比較して、相違がある場合には相違点を抽出する違反増減検出手段を更に有することを特徴とする請求項１〜８の何れかに記載のプログラム構造評価システム。
10. 前記評価対象のソフトウェアに対応する前記違反有無情報と、該評価対象のソフトウェアに関連する別のソフトウェアに対応して生成済みであった前記違反有無情報である前回違反有無情報とを相互に比較して、登録されている機能に相違がある場合には相違点を抽出する機能変化検出手段を更に有することを特徴とする請求項１〜９の何れかに記載のプログラム構造評価システム。
11. 他の複数のソフトウェアについてそれぞれ前記評価点数が算出済みである場合に、前記評価対象のソフトウェアの評価点数も含む該複数の評価点数に基づいて、前記評価対象のソフトウェアの評価点数について偏差値を算出する偏差値算出手段を更に有することを特徴とする請求項１〜１０の何れかに記載のプログラム構造評価システム。
12. 予め前記関数種別／変数種別毎に所定の重み値が登録された重み値記憶手段を更に有し、
    前記集計手段は、前記違反件数の集計の際に前記各関数種別／各変数種別毎の集計結果に対してそれぞれ該当する重み値を乗算して補正し、
    前記評価点数算出手段は、該補正後の集計結果に基づいて前記評価点数の算出を行うことを特徴とする請求項１〜１０の何れかに記載のプログラム構造評価システム。
13. 前記評価点数算出手段は、前記各機能毎の評価点数を算出する際に、前記各関数種別／各変数種別毎の違反件数の集計結果に基づいて、単位ステップ数当りの違反件数を求め、該単位ステップ数当りの違反件数に基づいて前記評価点数を求めることを特徴とする請求項１〜１１の何れかに記載のプログラム構造評価システム。
14. 前記評価点数算出手段は、前記単位ステップ数当りの違反件数に対して予め設定される足きりの閾値を用いて足きりを行った後の値を用いて前記評価点数を求めることを特徴とする請求項１２記載のプログラム構造評価システム。
15. 前記各機能は、それぞれ、１または複数のプログラムソースファイルによって実現され、
    前記各関数種別は、ＡＰＩ関数、ローカル関数であり、
    前記各変数種別は、グローバル変数、ローカル変数であることを特徴とする請求項１〜１４の何れかに記載のプログラム構造評価システム。
16. 前記プログラムソース文における前記関数／変数の名称には、その関数／変数の属する機能を示す情報と、その関数／変数の関数種別／変数種別を示す情報とが含まれていることを特徴とする請求項１〜１５の何れかに記載のプログラム構造評価システム。
17. 前記複数の機能より成るソフトウェアは、該複数の機能が階層化されたソフトウェア構造となっており、
    該ソフトウェアに係る前記機能間のアクセスに係る制限事項は、少なくとも相対的に下位側の機能から上位側の機能を呼び出すことは違反であること、及び、任意の機能から他の機能の前記ローカル関数／ローカル変数を呼び出すことであることを特徴とする請求項１６記載のプログラム構造評価システム。
18. 前記評価対象のソフトウェアは、組込みソフトウェアであり、
    前記階層化されたソフトウェア構造は、上位層がアプリケーション、中間層がミドルウェア、下位層がドライバであることを特徴とする請求項１７記載のプログラム構造評価システム。
19. 任意のソフトウェアについて所定の評価を行うためのコンピュータシステムにおいて、
    端末とサーバ装置とがネットワークに接続されたシステムであって、
    前記サーバ装置は、
    複数の機能より成るソフトウェアの機能間のアクセスに係る制限に従って、呼び出し元となる機能と呼び出し先となる機能の関数種別／変数種別との組み合わせである機能ペア毎に、違反の有無、または／及び、違反許容数が格納された違反有無情報を記憶する違反有無情報記憶手段と、
    評価対象のソフトウェアのプログラムソース文を順次参照して、任意の機能から他の機能の任意の関数／変数を呼び出す処理を検出する毎に、該呼び出し先の関数／変数の関数種別／変数種別を判別して、さらに前記違反有無情報を参照して、該呼び出しが違反か否かを判定する違反判定手段と、
    前記違反判定手段による判定結果に基づいて、前記各機能毎または／及び前記評価対象のソフトウェア全体の違反件数を集計する集計手段と、
    該集計手段による違反件数の集計結果に基づいて、前記評価対象のソフトウェア全体または／及びその各機能毎の評価点数を算出する評価点数算出手段と、
    予め、前記評価対象のソフトウェアに基づいて、前記違反有無情報を生成して前記違反有無情報記憶手段に記憶させる違反有無情報生成手段と、
    を有することを特徴とするプログラム構造評価システム。
20. コンピュータを、
    複数の機能より成るソフトウェアの機能間のアクセスに係る制限に従って、呼び出し元となる機能と呼び出し先となる機能の関数種別／変数種別との組み合わせである機能ペア毎に、違反の有無、または／及び、違反許容数が格納された違反有無情報を記憶する違反有無情報記憶手段と、
    評価対象のソフトウェアのプログラムソース文を順次参照して、任意の機能から他の機能の任意の関数／変数を呼び出す処理を検出する毎に、該呼び出し先の関数／変数の関数種別／変数種別を判別して、さらに前記違反有無情報を参照して、該呼び出しが違反か否かを判定する違反判定手段と、
    前記違反判定手段による判定結果に基づいて、前記各機能毎または／及び前記評価対象のソフトウェア全体の違反件数を集計する集計手段と、
    該集計手段による違反件数の集計結果に基づいて、前記評価対象のソフトウェア全体または／及びその各機能毎の評価点数を算出する評価点数算出手段と、
    予め、前記評価対象のソフトウェアに基づいて、前記違反有無情報を生成して前記違反有無情報記憶手段に記憶させる違反有無情報生成手段、
    として機能させるためのプログラム。
    
    

Images