JP2001290639A - ソフトウェア再構成方式 - Google Patents

Abstract

(57)【要約】 【課題】ソフトウェアの再利用性向上のため、規模や複
雑さを変えずにデータ取得に要する経路長を大きくする
方式を提案する。 【解決手段】ソフトウェアの実行時頻繁に呼び出される
データないし呼び出し元のデータを分割する。又、呼び
出されることの少ないデータないし呼び出し元のデータ
を統合する。分割と統合とを均等に実施することで全体
の経路長は変えずに、実際たくさん呼ばれている部分の
経路長を大きくとることが可能となる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はコンピュータ利用に
よるソフトウェア生産性向上に係わり、特にデータ構造
の規模等価な変換により複雑度を抑えつつ再利用性を向
上させる方式に関する。

【０００２】

【従来の技術】データの抽象度や構造の簡潔性、あるい
は派生データで再定義されている関数の割合がソフトウ
ェアの再利用性と強い関係にあると言われている。又、
データが受け取るメッセージの中で、あるデータからの
メッセージが全メッセージに占める割合をそのデータと
の依存度とする報告がある(オブジェクト指向ソフトウ
ェアの構造パターンに対するデータ解析手法による分析
評価の試み：信学技報KBSE95−2 P9−16 飯島正 他)。
又、データの他のデータからの独立性をソフトウェア再
利用性の因子とする報告(オブジェクトの独立性に関す
る考察：ソフトウェア工学92−5 P35−42 藤崎智宏 他)
では、データ間で直接メッセージを送り合っている場合
だけでなく、間に他のデータが介在する間接的な依存関
係も考慮に入れて独立性を求めている。

【０００３】一般的にソフトウェアを構成するデータの
独立性は高い(依存度が低い)方が無駄も少なく理解し易
いとされているが、再利用される側に関しては独立性が
低くデータ取得に要するメッセージの伝達経路が長い方
が良いとする報告がある。再利用する側ではメッセージ
の伝達経路が短い方が良いのは自明だからである。

【０００４】

【発明が解決しようとする課題】データ取得に要する経
路長はソフトウェアの規模や仕様により凡そ適する大き
さがある。経路長を大きくとるためだけにデータを分割
したり追加したりすれば不要なメッセージが増え性能劣
化をもたらすばかりでなく、データ構造が歪になり再利
用性を問う前にその部分が欠陥となりうる。そこで、規
模や複雑さは変更せずにデータ構造を変換する方式を提
案する。これをコンピュータによるソフトウェア設計支
援ツールに適用し、再利用を前提としたソフトウェア
(クラスライブラリ、アプリケーションフレームワーク)
の開発に用いる。又、通常のソフトウェアに関してもバ
ージョンアップや流用等そのライフサイクル中に再利用
される機会は多く、再利用されることを念頭に置いた開
発をしておくことが望ましい。

【０００５】

【課題を解決するための手段】再利用されるソフトウェ
アの構成データは取得に要するメッセージの伝達経路が
長い方が良いとする考えに基づき、既存データ構造を変
換する。ただしデータを分割し経路長を大きくるするだ
けでは問題のあることは「発明が解決しようとする課
題」で述べた通りである。

【０００６】そこでまず、ソフトウェアの実行履歴を取
得し頻繁に呼び出されるデータないし呼び出し元のデー
タを分割する。ここではデータの内包する属性を、同じ
くデータに内包される関数との関係を考慮しながら分け
ていく。中には複数の属性と関係を持つ関数があった
り、分割数も二つとは限らない場合も出てくるため自動
化は難しく、実際にはデータを生成する型の属性を振り
分けるのを助ける機能を提供することにより、ユーザー
は振り分け先の雛型を再設計することになる。

【０００７】次に、呼び出されることの少ないデータな
いし呼び出し元のデータを統合する。この際も二つの雛
型の属性を全て片方に集めてしまうだけでなく、集める
属性を選択することにより段階的な統合が可能となる。
又、一つの雛型の属性をを二つ以上の別の雛型に統合す
る機能を用意することでより柔軟な設計が可能となる。

【０００８】このように分割と統合とを均等に実施する
ことで経路長の総和を変えることなしに１メッセージあ
たりの経路長の期待値を大きくすることができる。すな
わちソフトウェアの規模や複雑さは分割と統合を加える
前と等価で、再利用が容易なデータ構造に変換すること
ができるのである。

【０００９】

【発明の実施の形態】本発明の一実施例を、以下図面に
従って説明する。

【００１０】図１は本発明の方式を用いる事により変化
するソフトウェア構造を示したものである。元となるソ
フトウェア(101)はデータの分離と統合を行うことで(10
8)となる。この図上でデータ間の関連の線が太くなって
いるのはその間の呼び出し回数が多いためである。例え
ばa−bの線幅はbの関数を利用するa側からの呼び出し回
数にaの関数を利用するb側からの呼び出し回数を加えた
値を示している。

【００１１】まず(101)においてその太い部分a−b(102
−103)に着目する。aとbは呼び出し頻度が高く互いに強
く依存し合っている。aのうちbの関連を利用しない部分
a2(110)をaより分割する。残りの部分をa1(109)と表わ
している。ここにはbを呼ぶために必要な属性と関数が
含まれる。これによりaを呼び出し元とした場合、呼び
出し経路はa→bからa1→a2、a1→bとなる場合と、a2を
利用しないa1→bとなる場合がある。つまり経路長の期
待値は増加する。

【００１２】b−c（103−104）についても呼び出し頻度
が高いので分割する。但し今度は呼び出し先のc(104)を
分割してc1(112)、c2(113)とする。c2はbとの関連にc1
を用いて実現しているので、呼び出し経路はb→cからb
→c1→c2となり経路長は増加する。

【００１３】このように分割を施すと経路長の期待値は
大きくなるが、データ間の関連も増えるため複雑さも増
大する。

【００１４】では次に呼び出し頻度の低いところに着目
する。図１のデータではb−d(103−105), e−f(106−10
7)がこれに当たる。dは他に呼び出し元もないためその
属性と関数をすべてbに移す。dの関数呼び出しがbの関
数の内部処理となるため、呼び出し経路はb→ dからbと
なり経路長は減少する。

【００１５】e−f を含むe−f−gについてはfの属性と
関数を呼び出し元のeと呼び出し先のg双方に振り分け
る。呼び出し経路はe→f→gからe→gとなり経路長は減
少する。

【００１６】このようにデータを統合すると経路長は小
さくなりこのデータ構造が意味するソフトウェアの複雑
さも減少する。

【００１７】さて以上の分割と統合の結果、101と102を
見比べてみると関連の数は8個で変わりない。関連を利
用したメッセージの経路長の総和が変化していないわけ
である。このことはすなわちこのソフトウェアの複雑さ
が変化していない事も意味している。ところが分割と統
合後の関連は呼び出し頻度の高いのが残っているため、
期待値としてのメッセージの経路長は大きくなってい
る。又、副産物として個々の関連の呼び出し頻度が均一
化されることも再利用性を高める一因となる。

【００１８】図２は、図１で説明した内容をを実現する
ための一システム構成を示す図である。実行中のプログ
ラム201から実行解析部202で一定期間履歴を取る。実行
解析部は汎用のデバッキングツールを用い、実際に起こ
った関数呼び出しの羅列である関数呼び出しリスト203
を再利用性管理ツール204に受け渡す。再利用性管理ツ
ールは本発明を実施するプログラムであり、呼び出し頻
度の高低で処理を振り分ける依存度判定部205と、デー
タが保有する属性および関数を分割するべくその候補を
選出するデータ分割部206と、複数のデータが保有する
属性および関数を一つのデータに変換するべくその候補
を選出するデータ統合部207と、実行中のプログラム201
のソースコード208より抽出されたデータの静的な関係
を示すソフトウェア構造図209で構成されている。この
構造図に206及び207で得られた結果を反映させ、元の構
造図と共にユーザーに表示し(210)変更を施す際の判定
材料とする。依存度判定部での判定基準である呼び出し
頻度とは、関数呼び出しリスト内の全関数呼び出しに対
する当該データ関連を用いている関数呼び出しの割合で
ある。

【００１９】この依存度判定部を実現する処理の流れを
図３に、データ分割部を実現する処理の流れを図４に示
す。再利用性管理ツール実行(301)後、個々のデータ関
連を判定する前に、実行解析部より取得した関数呼び出
しリストより全関数呼び出しの回数を全データ関連数で
割った値、すなわち平均呼び出し回数を求めておく(30
2)。これは図１における関連の線幅の平均値にあたる。
平均値が求まると、ソフトウェアを構成するデータ関連
(303)毎にそのデータ関連を利用する両端のデータに付
随する関数の呼び出し回数(304)を求める。図６に関数
呼び出しリストの例(601)を示す。(604,607)がa−b関連
を利用する両端のデータに付随する関数の呼び出しであ
る。別データ(602,603)、bからa(604)、a自身(605)、x
からa(606)、yからaからb(607)、Z型に付随する静的関
数(608)、自身又は外部関数(609)となっている。

【００２０】(304)と平均呼び出し回数(302)とを比較し
(305)、一定割合以上大きければデータ分割部(307)を実
行し、小さければデータ統合部(306)を実行し、どちら
でもなければここでは何も処理しない。

【００２１】ユーザーは提示されたデータ構造変更案か
ら選択するか、独自にデータ構造を変更する。変更案の
提示に関しては図４でデータ分割機能を説明する。独自
にデータ構造を変更する場合も、ユーザーにはデータを
生成する型の保有する属性を操作する機能と、関数や他
のデータ型との依存関係から操作が適切かどうかチェッ
クする機能を提供する。新たなデータ構造が決定すれば
それに伴うデータ関連の張り直しを行う。図５の(504)
に示したa2内のA1型へのポインタa1がこれにあたる。こ
うして新たに獲得したデータ構造とデータ関連とで、ソ
ースコードから抽出したソフトウェア構造のデータ関連
とデータ構造とを置換する(308)。すべてのデータ関連
を処理した後(309)終了する(310)。

【００２２】データ分割部ではまず当該データ関連を用
いて呼ばれている関数群とそうでないものを分離する(4
02)。図５のデータ構造図では分離前(501)のgetdousa
n()関数が前者にあたる。移した結果は(503、504)の下
段となっている。

【００２３】次に属性についても参照している関数の方
に移す(403)。(503) getdousan()関数では属性moneyとk
abuの値を取得している。移した結果は(503、504)の中
段となる。ここでa2(504)のgetshisan()関数はbから呼
び出されてはいないが、別に分離されてしまったa1(50
3)の属性を参照する必要が出てくる。この為にA1型のポ
インタa1をa2(504)に用意する(404)。最後にb(502)のA
型へのポインタaをA1型へのポインタa1に変換する(505)
ことで一連のデータ分割は終了する。

【００２４】この例ではただ一通りの分割の仕方となっ
たが、複数通りあったり、全くなかったりする。最終的
な選択はこの処理の終了(405)後、(308)でユーザーに決
定させる。

【００２５】データの統合に関しては、図1の(114→11
1)の様な場合がそのほとんどである。この場合は属性と
関数を移し、関連を用いて関数呼び出しをしていたのを
直接参照ないし自身の関数呼び出しに変更することにな
る。(115←116→117)の様な場合には上記処理の前に属
性と関数の振り分けを行っておく必要がある。これは丁
度データの分割で行った処理であり図４、５を用いて説
明した機能を用いることができる。相違点は分割先のデ
ータ型が既に存在している点である。

【００２６】

【発明の効果】以上説明したように本発明によってソフ
トウェアの規模や複雑さは変えずに、実際に多く呼ばれ
ている部分の経路長を大きくとることが可能となりソフ
トウェアの再利用性が向上する。

【図面の簡単な説明】

【図１】第１の実施例の方式概念図である。

【図２】第１の実施例を示すシステム構成図である。

【図３】第１の実施例の全体の処理の流れを示す図であ
る。

【図４】図３で示した一部分の処理の流れを示す図であ
る。

【図５】図２で示したソフトウェア構造図の一部分をな
すデータ構造図である。

【図６】図２で示した関数呼び出しリストを示す図であ
る。

【符号の説明】

101…変換を施す前のデータ構造、102〜107…101のデー
タ、108…変換を施した後のデータ構造、109〜117…108
のデータ。

Claims (3)

【特許請求の範囲】
1. 【請求項１】 ソフトウェアの実行履歴よりデータ間で
   の呼び出し頻度を測定する手段と、該測定結果に基づき
   データを分割ないし統合する手段を持つことを特徴とす
   るソフトウェア再構成方式。
2. 【請求項２】 前記呼び出し頻度を測定する手段は、前
   記データ間の参照回数を同一時間内の全データ参照回数
   で割って算出することを特徴とする請求項１記載のソフ
   トウェア再構成方式。
3. 【請求項３】 前記測定結果が閾値より高ければ前記デ
   ータ分割手段を用い、低ければ前記データ統合手段を用
   いることを特徴とする請求項１記載のソフトウェア再構
   成方式。