コンポーネントランクを用いた ソフトウェアのクラス設計に関する 分析手法の提案 市井　誠*，横森　励士** ，松下　誠*，井上　克郎* *大阪大学 大学院情報科学研究科 **南山大学 数理情報学部 情報通信学科

背景1: コンポーネントランク法 ソフトウェア部品検索システム SPARS で用いられる順位付け手法 ソフトウェア部品の重要度を，利用関係から評価し，順位付けする 多くの部品から利用されている部品は重要 重要な部品から利用されている部品もまた重要 多く利用される部品や，重要な箇所で利用される部品に大きな評価値が与えられる コンポーネントランク値(CR値) : 部品に与えられた評価値 コンポーネントランク(CR) : CR値による順位 まず，背景としてコンポーネントランク法について説明します。 2018/9/22

コンポーネントランク値の計算 C1 C2 C3 C1 C2 C3 C1 C2 C3 C1 C2 C3 C1 C2 C3 C1 C2 C3 部品グラフをもとにした繰り返し計算 各頂点に総和を1として適当な重みを与える 頂点の重みを，出ていく辺で分配する 入ってくる辺の重みの総和を，その頂点の重みとして再定義 頂点の重みが収束するまで，2.3.を繰り返し計算 収束した重みが部品のCR値 C1 0.334 C2 0.333 C3 C1 0.334 C2 0.333 C3 v1×50% v2×100% v3×100% C1 C2 C3 0.167 0.333 C1 0.333 C2 0.167 C3 0.500 C1 C2 C3 0.1665 0.167 0.500 C1 0.500 C2 0.1665 C3 0.3335 C1 0.400 C2 0.200 C3 2018/9/22

背景2: ソフトウェアのクラス設計 オブジェクト指向でのクラス設計 中心となるクラスは クラスごとに役割を持つ クラス同士が利用関係を持つ 中心となるクラスを知ることで概略が理解しやすくなる 中心となるクラスは 多くのクラスから利用される 中心となるクラス同士で利用関係をもつ コンポーネントランク法を利用する事で識別できるのではないか？ 単体のソフトウェアに対して適用すると，中心となるクラスが高く順位付けされる オブジェクト指向でのクラス設計について説明します。 オブジェクト指向では、通常、クラスごとに役割を持ち、 クラス同士が利用関係をもつ様に設計されます。 クラス設計を理解するには、まずは中心となるクラスを知る事が必要です。 中心となるクラスについて考えますと、 中心となるクラスは、多くのクラスから利用されるクラスです。 また、中心となるクラス同士で利用関係を持つ事も考えられます。 このような特徴から、我々は中心となるクラスはコンポーネントランク法を利用することで識別できるのではないか、 と考えました。 コンポーネントランクを単体のソフトウェアに対して適用した場合，中心となるクラスが高く順位付けされると考えられます． 2018/9/22

目的 ソフトウェアの理解支援を目的とした，コンポーネントランクに基くクラス設計分析手法を提案 コンポーネントランクにより中心的なクラスを識別する 中心的なクラスを基に，クラスの役割や利用関係を分析する そこで本研究では，コンポーネントランクを用いた，ソフトウェアの理解支援を目的としたクラス設計の分析を目的とします． 提案する手法では，まずコンポーネントランクにより中心的なクラスを識別し， それらのクラスを基にしてクラスの役割や利用関係を分析します． 2018/9/22

提案手法の概要 基本方針 SPARS-J 手順 CRの順位を基にクラスをグループ分け 順位の高いグループから，グループに含まれるクラスのみを分析 手順 CRの計算 重要クラスのグループの作成 CRをもとに，3グループ作成 重要クラスのグループの分析 順位の高いグループから グループ内のクラスの役割・関連を分析 SPARS-J Javaソースコード クラスをCR順にソート 順位を基に3グループ作成 1. ………………………………………… 2. ………………………………………… 3. ………………………………………… 4. ………………………………………… 5. ………………………………………… 6. ………………………………………… 7. ………………………………………… … 20.. ……………………………………… 21. ……………………………………… 50. ……………………………………… 51. ……………………………………… 基本方針としまして，CRの順位を基に，クラスを上位からグループ分けしていき， 順位の高いグループから順にグループに含まれるクラスのみを分析していきます． 手順の概要としては以下の通りです。 まず、ソフトウェア中の全ての部品に大してCRを求めます。 続いて，重要クラスのグループの作成を行います． これは，CRを基にして3グループ作成します． そして，重要クラスのグループの分析を行います． 分析内容としては，グループ内のクラスの役割および関連です． これは順位の高いグループから行います． グループごとにクラスを分析 2018/9/22

手順1: CRの計算 ソースコードを準備 SPARS-Jへ登録・CR値・CRの計算 結果の出力 単体ソフトウェアのソースコード 利用ライブラリや，ビルド情報は不要 SPARS-Jへ登録・CR値・CRの計算 結果の出力 CR値・CR 被参照数での順位 クラスを利用しているクラスの数 まず分析対象のソフトウェアのソースコードを準備します． これは単体ソフトウェアのソースコードを用意します． この時，利用ライブラリのJarアーカイブや，ビルド情報は不要です． 続いて，このソースコードをSPARS-Jへ登録する事でCR値を計算します． 最後に，結果を出力します． この時，それぞれのクラスのCR値とともに被参照数が求められていますので， その順位も合わせて出力します． 2018/9/22

手順2: 重要クラスのグループの作成 グループの閾値を設定する 閾値を基に，グループを作成 閾値(1) : 上位 3～10 クラス 閾値(2) : 上位 10% 閾値(3) : 上位 20% これらの閾値は，総クラス数やCR値の分布に応じて増減 閾値を基に，グループを作成 グループ(1) : 閾値(1)以上 グループ(2) : 閾値(2)以上 グループ(3) : 閾値(3)以上 続いて重要クラスのグループを作成する為に，閾値を設定します． この閾値は3段階で設定し， それぞれ，上位3～5クラス,上位10%,上位20%とします． なおこれらの閾値は総クラス数やCR値の分布に応じて増減させます． 設定した閾値を基にグループを作成します． グループ(1)は閾値(1)以上のクラス， グループ(2)は閾値(2)以上閾値(1)未満のクラス， グループ(3)は閾値(3)以上閾値(2)未満のクラスとします． 2018/9/22

手順3:重要クラスのグループの分析 (1/2) グループ(1),(2),(3)の順で，グループ内のクラスの分析を行う 共通する分析内容 クラスの役割 クラス名が役割をあらわしている ドキュメンテーションコメントに記述されている クラス間の関連 SPARS-Jの利用関係表示機能を利用し，取得する ソースコードから生成したクラス図を利用する クラスの，被参照数での順位とCRとの差 差が大きいクラスに関しては設計的な要因がある CRでの方が高順位：重要な箇所で利用されている 被参照数での方が高順位：広範囲からユーティリティ的に利用されている グループ(1),(2),(3)の順で，それぞれのグループ内のクラスの分析を行います． それぞれ分析内容は少しずつ異なりますが，共通する分析内容としては，クラスの役割・クラス間の関連・クラスの被参照数での順位とCRとの差です． クラスの役割は，クラス名や，ドキュメンテーションコメントから得ます． クラス間の関連は，SPARS-Jの利用関係表示機能を利用して得ます． ソースコードからのリバースエンジニアリングにより生成したクラス図も利用します． 被参照数での順位とCRとの差を見たとき，差が大きいクラスに関しては設計的な要因があると考えられます． CRでの方が高順位である場合は，重要な箇所で利用されている事が考えられ， 逆に，被参照数での方が高順位の場合は，広範囲からユーティリティ的に利用されている事や，局所的に利用されている事が考えられます． --- クラス図の生成: あまり詳しい情報は必要ない．クラス名と，重要な関連のみが望ましい． 被参照数順位とCRの差: 「差が大きい」→差が2桁くらい 「局所的に」→あまり重要でない部分で，局所的に．例えばデータ読み込み部分とか． 2018/9/22

手順3:重要クラスのグループの分析 (2/2) 含まれる全てのクラスについて分析 役割の分析 クラス間の関連の分析 手順3:重要クラスのグループの分析　(2/2) グループ(1)の分析 含まれる全てのクラスについて分析 役割の分析 可能ならば他のドキュメントも参照 クラスそのものや，クラスの役割に関するドキュメント メソッド名・フィールド名なども参考にする グループ(2)の分析 クラス間の関連の分析 グループ(2)に含まれるクラスでクラス図を生成 グループ(1)のクラスとの関連に注意する グループ(3)の分析 グループ(3)に含まれるクラスでクラス図を生成 グループ(1),(2)との関連を持つクラスを優先的に分析 関連の中でも，フィールド宣言や継承などのより強い関連を重視する 数が多い時は，関連を持たないクラスや下位のクラスは省略する それぞれのグループでの分析内容について説明します． まずグループ(1)ですが，全てのクラスについて分析します． また，役割の分析として，クラス名およびドキュメンテーションコメントだけで無く， 可能ならば他のドキュメントも参照します． 参照するのは，クラスそのものや，クラスの役割に関するドキュメントです． また，メソッド名やフィールド名からは，操作や属性が得られるので，これらも参考にします． グループ(2)では，クラス間の関連の分析時に使用するクラス図は グループ(2)だけでなくグループ(1),(2)両方に含まれるクラスで生成します． また，グループ(1)のクラスとの関連に注意します． グループ(3)では，同様にクラス間の分析時にグループ(1)から(3)に含まれるクラスで生成します． また，グループ内のクラスを分析する順番は，上位から見ていくのではなく，グループ(1)および(2)との関連を持つクラスを 優先的に分析します． この時，関連には様々な種類が有りますが，フィールド宣言や継承などの，より強い関連を重視します． また，グループ内のクラス数が多いときは，グループ(1),(2)との関連を持たないクラスや，下位のクラスは省略します． --- 「ソースコードから生成したクラス図を利用する」：SPARS-Jとあわせて利用 2018/9/22

適用実験 提案手法の有効性を評価するために，実際のソフトウェアに対して適用実験を行った 対象 研究室内で開発されたソフトウェア 企業で開発されたソフトウェア 手法の一部のみを適用 提案手法の有効性を検証する為，実際のソフトウェアに対して適用実験を行いました． 対象ソフトウェアは2つです． ひとつは，研究室内で開発されたソフトウェアで， もう一つは，ある企業で開発されたソフトウェアです． なお，企業のソフトウェアについては，実験を相手先で行い時間の制約があったため，手法の一部のみを適用しました． 2018/9/22

適用実験(1): 研究室内で開発されたソフトウェア メトリクスグラフを操作して条件指定 コードクローン分析ツールAriesのクローン情報表示部 Java GUIアプリケーション 283クラス，約3万行 リファクタリング可能なクローンをメトリクスに基づき絞り込む クローン情報を読み込み，メトリクスグラフを表示 メトリクスグラフを操作し，クローンを絞り込む 条件に合致するクローンの情報を表示 条件に合うクローンセットの一覧 選択したクローンセットに含まれるクローンの情報 まず研究室内で開発されたソフトウェアでの適用実験について説明します． 対象ソフトウェアは，コードクローン分析ツールAriesのクローン情報表示部です． これは，JavaのGUIアプリケーションであり，283クラス，約3万行です． 主要な機能は，「検出されたクローンの中から，リファクタリング可能なクローンを，そのメトリクスを基に絞り込む」というものです． この機能は以下の3段階の操作で行います． まず，解析済みのクローン情報を読み込み，メトリクスグラフ(上の図の線グラフ)を表示します． このグラフは閾値をドラッグにより操作出来るようになっています． 続いて，適用したいリファクタリングパターンに対応した閾値をグラフを操作する事によって指定すると，条件にあうクローンセットが絞り込まれます(上の図のテーブル) その中から選択すると，そのクローンセットに関する情報が表示されます．(下の図) --- 前日にクローンネタの発表があるので，「クローンセット」に関しては無説明で大丈夫なのではないかと． 下の図: 上半分のテーブルが，クローンセットに含まれるクローン一覧． ここから一つ選択すると，下半分にソースコードとその情報が表示される． 2018/9/22

CRの計算・グループ作成 CR値の分布 閾値は以下の様に決定 上位が極端に高い 一般的なCR値の分布 5クラスほどが特に高い 閾値(1):上位5クラス 閾値(2):10% 上位28クラス 閾値(3):20% 上位57クラス 適用結果について説明していきます． まずCR値の計算結果ですが，分布はグラフの様になっています． このグラフは縦軸がCR値・横軸がクラスとなっており，クラスはCR値の高い順にソートされています． 分布は，上位が極端に高く，以降なだらかになるという指数的な分布になっており，これは一般的なCR値の分布となっています． 上位の中でも，5クラスほどが特に高い値となっています． この分布より，閾値(1)は上位5クラス,閾値(2)は10%,閾値(3)は20%と決定しました． 閾値(2),(3)についてはそれぞれ28クラス，57クラスであり，分析に問題のないクラス数だと考えられます． 2018/9/22

重要クラスの分析 クラス図の生成 UMLモデリングツール Jude を使用 出力される関連辺 グループ(2)以降で使用 継承 実装 クラスのフィールドとして宣言 グループ(2)以降で使用 グループ(1)では，関連辺がほとんど引かれないため参考にならない 関連の分析時に用いるクラス図の生成は，UMLモデリングツールであるJudeを使用しました． このツールでは，「継承」「実装」および「クラスのフィールドとして宣言」とき，クラス間の関連辺が出力されます． つまり，辺が無くても，ローカル変数宣言など，別の形での関連があるかもしれない，という事ですが， より強い関連のみが表示される，という事で分析に問題は無いと考えられます． また，クラス図はグループ(2)以降の分析で利用しました． これは，グループ(1)ではあまり参考にならない為です． --- 辺が無くても，別の形で関連があるかもしれない． しかしここであらわされる関連はより強い関連であると言える． 注:フィールドとして宣言されていても，CollectionやListといった集合で宣言されている時は関連が引かれない グループ1: クラス数が少ない為，クラス図は無くても特に支障は無い． 2018/9/22

重要クラスの分析:グループ(1) グループ(1)の5クラス 考察 CloneSet Variable Fragment クローンセットをあらわす抽象クラス. フィールドとして各種メトリクス値をもつ. Fragment（3位）の集合をもつ． Variable クローンの外部で定義される変数(外部定義変数)を表すクラス. 被参照数と比較してCRは高順位 Fragment クローンとなるコード片の情報. Variable(2位)の集合をもつ. DecralationUnit クラスやインタフェースを表すクラス． PackageName(５位)をフィールドとして持つ. PackageName パッケージ名およびクラス名を表すクラス 考察 重要なデータの構成要素を表現するクラスが上位に クローン分析時の重要な概念であるクローンセットおよびその関連クラスが確認できた 外部定義変数はクローンとは直接関係無いが，重要な概念 クローンがリファクタリング可能かを調べるために外部定義変数の個数を利用 重要クラスの分析結果を，グループ(1)から説明していきます． 以降の説明では，クラスに関してはパッケージ名は省略します． グループ(1)は以下の5クラスです．これは上位から順に並べています． まず1位はCloneSetというクラスで，これはクローンセットをあらわす抽象クラスです． フィールドとして，各種メトリクス値を持ちます．また，後で説明する Fragment クラスの集合をもちます． 2位はVariableというクラスで，これはクローンの外部で定義され，クローン中で使用される変数である外部定義変数をあらわします． 被参照数では17位なのに対して高順位であり重要な部分で利用されていると考えられます． 3位はFragmentというクラスで，これはクローンとなっているコード片の情報をもつクラスです． Variableの集合をフィールドとしてもっています． 4位はDeclarationUnitというクラスで，これは単体のクラスをあらわします． 5位のPackageNameをフィールドとして持っています． 5位はPackageNameというクラスで，これはパッケージ名およびクラス名をあらわします． 以上を考察します． ・グループ(1)から，クローン分析時の重要な概念である，クローンセットおよびその関連クラスが確認できました． ・また，外部定義変数は，一般のクローン分析とは直接関係ありませんが，重要な概念である事がわかりました． 　実際に，クローンのメトリクスの一つとして，外部定義変数の個数が定義されており，リファクタリング可能/不可能の条件として利用されています． 2018/9/22

重要クラスの分析: グループ(2) 特徴的なクラスを抜粋して説明 StatementCloneSet 文単位のクローンをあらわす MetricsGraphから利用されている ProcessCloneSet, DeclarationCloneSet それぞれ，メソッド単位のクローン，クラス単位のクローン パッケージ名のみが異なる別の MetricsGraph から利用されている 続いてグループ(2)のクラスの分析について説明していきます． ここでは，特徴的なクラスを抜粋して説明してきます． まず，StatementCloneSetというクラスに注目します． このクラスは，グループ(1)のCloneSetのサブクラスであり，文単位のクローンをあらわしています． また，このクラスはMetricsGraph という，同じくグループ(2)のクラスから利用されています． なお，MetricsGraphクラスは，パッケージの異なる同名クラスが合計3個存在しています． StatementCloneSetと同様，CloneSetを継承したクラスとして，ProcessCloneSet, DeclarationCloneSetクラスがあります． これらはそれぞれメソッド単位のクローンおよびクラス単位のクローンであり， StatementCloneSetを利用するMetricsGraphクラスとは別のパッケージのMetricsGraphクラスから利用されています． --- StatementCloneSet 15位 ProcessCloneSet 19位 DeclarationCloneSet 21位 2018/9/22

重要クラスの分析: グループ(2) CloneGroup 同種の依存関係をもつクローンの集合をあらわすクラス DeclarationUnitData DecralationUnitの集合を扱うクラス 同様の集合を扱うクラスとして， VariableData, CloneSetData,など GUI部品 ClassListViewPopupMenu, PackageTreePopupMenu, SourceCodePainView, MetricsGraph, … 名前が役割をそのままあらわしている 考察 主要なGUI部品であるメトリクスグラフと，そこで扱われるCloneSetのサブクラスがわかった クローングループは重要な概念であるが，比較的順位が低い 最近実装されたばかりで，ソフトウェア中で占める割合が低いと考えられる GUI部品として，ポップアップメニューのクラスが上位 ポップアップメニューが多用されている事がわかる 画面そのものよりも上位に来ることは，理解の妨げになるかもしれない 続いて，CloneGroupクラス，DeclarationUnitDataクラス，およびGUI部品のクラスについて説明します． CloneGroupクラスは，依存関係を持つクローンである，クローングループをあらわすクラスです． DeclarationUnitDataクラスは，グループ(1)のDeclarationUnitクラスの集合をあらわしています． 同様に，集合をあらわすクラスとして VariableDataクラス，CloneSetDataクラスがあり，それぞれVariableの集合，CloneSetの集合をあらわしています． GUI部品として， ClassListViewPopupMenu, PackageTreePopupMenu, SourceCodePainView, MetricsGraph, …などがあります． これらは，名前がそのまま役割をあらわしています． 以上の考察として， ・主要なGUI部品であるメトリクスグラフをあらわすクラスと，そこで扱われるCloneSetのサブクラスがわかりました． ・クローングループは直感的には重要な概念であるにも関わらず，比較的順位が低い位置にありました． 　これは，最近実装されたばかりの機能で，ソフトウェア中で占める割合が低い為であると考えられます． ・GUI部品として，ポップアップメニューを実現するクラスが上位にきていました． 　これよりポップアップメニューが多用されている事がわかりますが，ポップアップメニューの使用される画面そのものより上位であり， 　理解の妨げになっているかもしれません． 2018/9/22

重要クラスの分析: グループ(3) StatementCloneSetData CloneSetDataのサブクラス MetricsGraphから，フィールドとして利用されている よく似た利用関係を持つクラス群がいくつか存在 続いてグループ(2)のクラスの分析について説明していきます． ここでも，特徴的なクラスを抜粋して説明してきます． StatementCloneSetDataクラスに注目します． このクラスはグループ(2)のCloneSetDataクラスのサブクラスであり，StatementCloneSetの集合をあらわしています． また，MetricsGraphからフィールドとして利用されています． また，ProcessCloneSetData, DeclarationCloneSetDataも同様の関係となっています． クラス図ではこのように表現されています． 2018/9/22

重要クラスの分析: グループ(3) CloneSetView クローンセットの情報を表示するテーブル パッケージのみが異なる同名クラスが合計3個存在 それぞれ，StatementCloneSet, ProcessCloneSet, DeclarationCloneSet のいずれかをフィールドとして持つ． FragmentViewの親コンテナ クローンとなるコード片に関する情報を表示 考察 クローンや変数といった実体をあらわすクラスと，GUI部品との関連が確認できた CloneSetViewクラスについて説明します． このクラスはクローンセットの情報を表示するテーブルを実現するクラスであり， パッケージのみが異なる同名クラスが3個存在します． それぞれ， StatementCloneSet, ProcessCloneSet, DeclarationCloneSet のいずれかをフィールドとして持ちます． また，クローンとなるコード片に関する情報を表示するFragmentViewクラス の親コンテナです． なおFragmentViewクラスはグループ(3)に含まれます． この関係は，クラス図ではこのように表現されています． 以上より，グループ(3)では， グループ(1)で出てきたクローンや変数といった実体をあらわすクラスと，GUI部品との関連を確認できました． 2018/9/22

適用実験(1):まとめ Aries 表示部の主要な機能に関連するクラスを確認できた Aries 表示部の設計の特徴を捉える事ができた 重要なデータを表現するクラスと，その利用の流れの概略が確認できる クローンや関連する概念を表現するクラス メトリクスグラフを実現するクラス Aries 表示部の設計の特徴を捉える事ができた 集合をあらわすクラスが使われている よく似た利用関係を持つクラス群がいくつか確認できた パターンの存在を認識しておくと理解の助けになる 以上の，研究室内で開発されたソフトウェアに対する適用実験についてまとめます． Aries表示部の主要な機能に関連するクラスを確認する事ができました． 具体的には，クローンや，関連する概念を表現するクラスや， メトリクスグラフなどのGUI部品を実現するクラスです． また，Aries表示部の設計の特徴を捉える事ができました． 具体的には，集合を扱う時にCollectionなどではなく，集合をあらわすクラスが定義され使われている点，および， クローンは，文やメソッドといったその単位により，別のクラスによって扱われている，という点です． 2018/9/22

適用実験(2): ある企業で開発されたソフトウェア Webアプリケーション データベース・ロジック・プレゼンテーションの3層構造 それぞれのレイヤーを担当するクラスの他に，エンティティクラス等の共通クラス，レイヤー間のデータ受け渡しを行うクラスが存在 約850クラス, 11万行 グループ(1) の分析のみ行った 閾値(1)は，10クラスに設定 JSPファイルは登録しない Javaファイルへ変換する必要があるが，環境依存であり自動化できていない つづいてある企業で開発されたソフトウェアに対する適用実験について説明します． このソフトウェアはデータベース・ロジック・プレゼンテーションの3層構造のWebアプリケーションです． それぞれのレイヤーを担当するクラスの他に，エンティティクラス等の共通クラス，レイヤー間のデータ受け渡しを行うクラスが存在します． 規模は，約850クラス，11万行です． グループ(1)の分析のみ行いました． 閾値(1)は10クラスとしました． なお，WebアプリケーションでHTML画面出力に利用される JSPファイルは登録を行いませんでした． SPARS-Jへ登録するためにはJavaファイルへ変換する必要がありますが，この変換は環境に依存し自動化できていない為です． 2018/9/22

結果 グループ(1)に含まれるクラス 開発者への聞き取りにより，重要なクラスである事を確認 考察 エンティティクラス（共通クラス）が5クラス ユーティリティクラス（共通クラス）が2クラス データ受け渡しのクラスが3クラス 開発者への聞き取りにより，重要なクラスである事を確認 考察 JSPファイルを登録しなかった為，利用関係が不完全 レイヤー間の受け渡しは局所的なクラスで上位なのは不自然とも考えられる JSPファイルも出来る限り登録したら，結果が変わる可能性はある 実際に大きな部分を占めている可能性は高い 関連する2レイヤー(データベース,ロジック)で全体の半分以上の480クラス データ受け渡しがそれぞれのレイヤー中で幅広く利用されている 実験の結果について説明します． グループ(1)に含まれるクラスとしては， ・共通のエンティティクラスが5クラス ・ユーティリティクラスが2クラス ・データ受け渡しのクラスが3クラス でした． これらのクラスは，開発者への聞き取りにより，重要なクラスである事が確認できました． しかし，レイヤー間の受け渡しは局所的な役割であり，そのクラスが上位なのは不自然とも考えられます． この理由として，以下の2点が考えられます． ひとつは，実際に大きな部分を占めている事が考えられます． 関連するレイヤーであるデータベース・ロジックで全体の半分以上の480クラスを占めており， これらのレイヤーをつなぐクラスが上位に来るのは自然な事だ，と考えられます． もう一つは，JSPファイルを登録しなかったために，利用関係が不完全であったため，と考えられます． JSPファイルも，Javaのクラスに対する利用関係をもつため，これらの登録を行っていれば， JSPファイルから利用されるクラスの順位が上がり，データ受け渡しのクラスは相対的に下がる，と考えられます． これより，JSPファイルも，出来る限り登録が必要である，と考えられます． 2018/9/22

まとめ コンポーネントランク法を用いてソフトウェアのクラス設計を分析する手法を提案 実際のソフトウェアに対する適用実験により，有効性を確認 主要なデータとその利用の流れがわかりやすくなる 今後の課題 適切な閾値の設定方法 クラス図の自動生成 より多くの適用実験 ではまとめさせていただきます． コンポーネントランク法を用いてソフトウェアのクラス設計を分析する手法を提案しました． また，実際のソフトウェアに対する適用実験により，有効性を確認しました． 今後の課題としては，まず適切な閾値の設定方法が上げられます． 今回は分布や総クラス数から決定して良好な結果が得られましたが， 一般のソフトウェアに対して適用できるかどうか分からないため， 一般に適用できるような値の決め方が課題となります． また，クラス図は一般のUMLツールを利用しましたが， グループ内のクラスを選択して図に加えるという作業は手間なので， 自動的に生成する事が望ましいと考えられます． 最後に，より多くの適用実験が挙げられます. 2018/9/22

終わり 2018/9/22

参考スライド 2018/9/22

クラス図: グループ(1),(2) 2018/9/22

クラス図: グループ(1),(2),(3) 2018/9/22

コピーした図が大きすぎるため、貼り付けできません。 クラス図:全部 コピーした図が大きすぎるため、貼り付けできません。 無理でした 2018/9/22

クラス図:全部(縮小) Judeは自動レイアウトが比較的きれいな方ですが，280クラスあるとこういう事になります． 2018/9/22