(57)【要約】【課題】概念データモデルで表現したシステムに存在する冗長性又は煩雑性の除去を支援すること。【解決手段】概念データモデル修正支援プログラムは、概念データモデルを表現するクラス図について、冗長性又は煩雑性を示す所定の条件に該当する箇所の有無を判定する判定部と、前記判定部による判定結果に基づく情報を出力する出力部と、としてコンピュータを機能させる。【選択図】図２
2018041363.tif 000002
【特許請求の範囲】
【請求項１】
概念データモデルを表現するクラス図について、冗長性又は煩雑性を示す所定の条件に該当する箇所の有無を判定する判定部と、
前記判定部による判定結果に基づく情報を出力する出力部と、
としてコンピュータを機能させることを特徴とする概念データモデル修正支援プログラム。
【請求項２】
前記判定部によって前記所定の条件に該当すると判定された箇所を、前記所定の条件に該当しない状態に修正する修正部、
としてコンピュータを機能させることを特徴とする請求項１記載の概念データモデル修正支援プログラム。
【請求項３】
前記出力部は、前記判定部によって前記所定の条件に該当すると判定された箇所を、他の箇所と区別して出力する、
ことを特徴とする請求項１又は２記載の概念データモデル修正支援プログラム。
【請求項４】
前記所定の条件は、
クラス名が同じ複数のクラスが存在すること、
及び、クラス名は異なるが属性が一致する複数のクラスが存在すること、
及び、クラス名は異なり属性に相違点が有るが、閾値以上の数の属性が共通する複数のクラスが存在すること、
及び、クラス名は異なるが、他のクラスとの関係性が同じである複数のクラスが存在すること、
及び、多重度が１対１又は、１対０．．１の関係線が存在すること、
及び、関係線が集中しているクラスが存在すること、
及び、異なるシステムに属するクラス間の関係線の数が閾値以上であること、
及び、閾値以上の階層の継承関係が存在すること、
及び、関連するクラス間において同一名の属性が存在すること、
及び、クラス同士が正規化されていないこと、
及び、補足情報が付加されているクラスが存在すること、
のいずれか１以上の条件を含む、
ことを特徴とする請求項１乃至３いずれか一項記載の概念データモデル修正支援プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概念データモデル修正支援プログラムに関する。
【背景技術】
【０００２】
大規模ソフトウェアについては、仕様が複雑化するため、仕様を分かりやすく表現する文書の作成が困難である。したがって、ソフトウェアの改良等を行おうとした場合に、仕様の理解が困難となり、改良作業等の支障となっている。
【０００３】
そこで、概念データモデルを利用してソフトウェアの仕様を表現することで、仕様の理解の容易化や、関係者間での意識の共有の促進等を期待することができる。その結果、概念データモデルをベースに関係者での議論が促進され、改良前のソフトウェアにおける問題点の洗い出しや、当該問題点の解決方法の検討がはかどることが期待できる。
【０００４】
データモデリング方法に関する従来技術は有るが（例えば、特許文献１）、概念データモデルを使った関係者での意識共有のための技術は見当たらない。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１１−１５４６５３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、大規模なソフトウェアであるほど、概念データモデルの規模も大きくなり、概念データモデルが表す当該ソフトウェアの構造において、冗長性や煩雑性が多く存在してしまう可能性が有る。その結果、改造開発やシステム更改時の開発において、新規システムの設計及び開発作業に手戻りが生じ、これらの作業を非効率なものにしてしまう可能性が有る。
【０００７】
本発明は、上記の点に鑑みてなされたものであって、概念データモデルで表現したシステムに存在する冗長性又は煩雑性の除去を支援することを目的とする。
【課題を解決するための手段】
【０００８】
そこで上記課題を解決するため、概念データモデル修正支援プログラムは、概念データモデルを表現するクラス図について、冗長性又は煩雑性を示す所定の条件に該当する箇所の有無を判定する判定部と、前記判定部による判定結果に基づく情報を出力する出力部と、としてコンピュータを機能させる。
【発明の効果】
【０００９】
概念データモデルで表現したシステムに存在する冗長性又は煩雑性の除去を支援することができる。
【図面の簡単な説明】
【００１０】
【図１】第１の実施の形態における概念データモデル修正支援装置のハードウェア構成例を示す図である。
【図２】第１の実施の形態における概念データモデル修正支援装置の機能構成例を示す図である。
【図３】第１の実施の形態における概念データモデル修正支援装置が実行する処理手順の一例を説明するためのフローチャートである。
【図４】第１の実施の形態におけるクラス図の修正例を示す図である。
【図５】第２の実施の形態におけるクラス図の修正例を示す図である。
【図６】第３の実施の形態におけるクラス図の修正例を示す図である。
【図７】第４の実施の形態におけるクラス図の修正例を示す図である。
【図８】第５の実施の形態におけるクラス図の修正例を示す図である。
【図９】第６の実施の形態におけるクラス図の修正例を示す図である。
【図１０】第７の実施の形態におけるクラス図の修正例を示す図である。
【図１１】第８の実施の形態におけるクラス図の修正例を示す図である。
【図１２】第９の実施の形態におけるクラス図の修正例を示す図である。
【図１３】第１０の実施の形態におけるクラス図の修正例を示す図である。
【図１４】第１１の実施の形態におけるクラス図の修正例を示す図である。
【発明を実施するための形態】
【００１１】
以下、図面に基づいて第１の実施の形態を説明する。図１は、第１の実施の形態における概念データモデル修正支援装置のハードウェア構成例を示す図である。図１の概念データモデル修正支援装置１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、インタフェース装置１０５、表示装置１０６、及び入力装置１０７等を有する。
【００１２】
概念データモデル修正支援装置１０での処理を実現するプログラムは、ＣＤ−ＲＯＭ等の記録媒体１０１によって提供される。プログラムを記憶した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。
【００１３】
メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従って概念データモデル修正支援装置１０に係る機能を実現する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。表示装置１０６はプログラムによるＧＵＩ（Graphical User Interface）等を表示する。入力装置１０７はキーボード及びマウス等で構成され、様々な操作指示を入力させるために用いられる。
【００１４】
図２は、第１の実施の形態における概念データモデル修正支援装置の機能構成例を示す図である。図２において、概念データモデル修正支援装置１０は、クラス図入力部１１、修正箇所判定部１２、出力部１３、及び修正部１４等を有する。これら各部は、概念データモデル修正支援装置１０にインストールされた１以上のプログラム（概念データモデル修正支援プログラム）が、ＣＰＵ１０４に実行させる処理により実現される。概念データモデル修正支援装置１０は、また、クラス図記憶部１５を利用する。クラス図記憶部１５は、例えば、補助記憶装置１０２、又は概念データモデル修正支援装置１０にネットワークを介して接続可能な記憶装置等を用いて実現可能である。
【００１５】
クラス図記憶部１５には、ソフトウェア設計のためのデータ構造を抽象化して表現した概念データモデルを示すクラス図のデータ（以下、単に「クラス図」という。）であって、本実施の形態において評価対象とされるクラス図が記憶されている。クラス図は、例えば、ＵＭＬ（Unified Modeling Language）で記述されていてもよいし、他の記法によって記述されていてもよい。
【００１６】
クラス図入力部１１は、クラス図記憶部１５からクラス図を読み込む。修正箇所判定部１２は、読み込まれたクラス図について、冗長性又は煩雑性を示す条件（端的に言えば、悪い構造を示す条件）に該当する箇所の有無を判定する。当該条件に該当する箇所は、修正候補とされる。そこで、当該条件を、以下「修正条件」という。
【００１７】
出力部１３は、修正箇所判定部１２による判定結果に基づく情報を出力する。例えば、出力部１３は、修正条件に該当する箇所を示す情報を出力する。修正部１４は、修正条件に該当する箇所を修正するための処理を実行する。
【００１８】
以下、概念データモデル修正支援装置１０が実行する処理手順について説明する。図３は、第１の実施の形態における概念データモデル修正支援装置が実行する処理手順の一例を説明するためのフローチャートである。
【００１９】
ステップＳ１０１において、クラス図入力部１１は、クラス図記憶部１５からクラス図を読み込む。続いて、修正箇所判定部１２は、修正条件に該当する箇所の有無を判定する（Ｓ１０２）。第１の実施の形態において、修正条件は、クラス名が同じ複数のクラスが存在することである。すなわち、クラス名が同じ複数のクラス群は、同一の機能又は概念を示している可能性が高く、このようなクラス群の存在は、クラス図が対象とするシステムの冗長化又は煩雑化を招く可能性が高いからである。
【００２０】
修正条件に該当する箇所が無い場合（Ｓ１０３でＮｏ）、図３の処理手順は終了する。修正条件に該当する箇所（以下、「修正候補箇所」という。）が有る場合（Ｓ１０３でＹｅｓ）、出力部１３は、修正候補箇所を示す情報を出力する（Ｓ１０４）。例えば、出力部１３は、クラス図を表示装置１０６に表示し、表示されたクラス図において、修正候補箇所を他の箇所と区別して表示する。斯かる区別は、ハイライト表示によって実現されてもよいし、マーキング、枠の付加、矢印の付加、吹き出し等の付加によって実現されてもよい。
【００２１】
続いて、修正部１４は、クラス図について、修正候補箇所を修正する（Ｓ１０５）。
【００２２】
図４は、第１の実施の形態におけるクラス図の修正例を示す図である。図４において、（１）は、修正前の状態を示し、（２）は、修正後の状態を示す。なお、図４に示されるクラス図において、属性は省略されている。
【００２３】
（１）に示されるクラス図には、クラス名が「社員」である社員クラスが２つ存在している。したがって、２つの社員クラスは、修正条件に該当する。よって、ステップＳ１０４において、２つの社員クラスは、例えば、ハイライト表示される。
【００２４】
ステップＳ１０５において、修正部１４は、２つの社員クラスを一つに統合する。この際、各社員クラスに接続していた関係線は、統合後の社員クラスに接続される。その結果、（２）に示されるような、シンプル化、コンパクト化、及び明確化されたクラス図が得られる。
【００２５】
次に、第２の実施の形態について説明する。第２の実施の形態では第１の実施の形態と異なる点について説明する。第２の実施の形態において特に言及されない点については、第１の実施の形態と同様でもよい。
【００２６】
第２の実施の形態において、修正条件は、クラス名は異なるが属性が一致する複数のクラスが存在することである。このようなクラス群は、同一の機能又は概念を示している可能性が高く、クラス図が対象とするシステムの冗長化又は煩雑化を招く可能性が高いからである。
【００２７】
図５は、第２の実施の形態におけるクラス図の修正例を示す図である。図５において、（１）は、修正前の状態を示し、（２）は、修正後の状態を示す。
【００２８】
（１）に示されるクラス図において、社員クラスと研究員クラスとの属性は、完全に一致している。したがって、社員クラス及び研究員クラスは修正条件に該当する。よって、図３のステップＳ１０４において、社員クラス及び研究員クラスは、例えば、ハイライト表示される。
【００２９】
この場合、図３のステップＳ１０５において、修正部１４は、社員クラス及び研究員クラスを一つに統合する。この際、社員クラス及び研究員クラスのそれぞれに接続していた関係線は、統合後のクラスに接続される。その結果、（２）に示されるような、シンプル化、コンパクト化、及び明確化されたクラス図が得られる。
【００３０】
なお、統合後のクラスのクラス名（図５の（２）では「社員」）は、ユーザによって入力されてもよい。例えば、修正部１４は、統合後のクラスのクラス名を入力させる画面を表示装置１０６に表示し、当該画面を介して入力されたクラス名を、統合後のクラスに適用してもよい。
【００３１】
次に、第３の実施の形態について説明する。第３の実施の形態では第１の実施の形態と異なる点について説明する。第３の実施の形態において特に言及されない点については、第１の実施の形態と同様でもよい。
【００３２】
第３の実施の形態において、修正条件は、クラス名は異なり、属性に相違点が有るが、閾値以上の数の属性が共通する複数のクラスが存在することである。このようなクラス群は、同一の機能又は概念を示している可能性が高く、クラス図が対象とするシステムの冗長化又は煩雑化を招く可能性が高いからである。なお、閾値は、例えば、比較される各クラスのそれぞれの半数であってもよいし、比較される各クラスのそれぞれの６割等であってもよい。
【００３３】
図６は、第３の実施の形態におけるクラス図の修正例を示す図である。図６において、（１）は、修正前の状態を示し、（２）は、修正後の状態を示す。
【００３４】
（１）に示されるクラス図において、一般社員クラスと研究員クラスとの属性は、研究員クラスに所属名が有る点において相違するが、所属名以外について一致している。したがって、一般社員クラスと研究員クラスとは修正条件に該当する。よって、図３のステップＳ１０４において、社員クラス及び研究員クラスは、例えば、ハイライト表示される。
【００３５】
この場合、図３のステップＳ１０５において、修正部１４は、社員クラス及び研究員クラスに対して上位概念に該当する抽象クラスを生成し、当該抽象クラスと社員クラス及び研究員クラスとの間に汎化関係を生成する。修正部１４は、社員クラス及び研究員クラスにおいて共通する属性を当該抽象クラスに含めると共に、当該共通する属性を社員クラス及び研究員クラスから削除する。修正部１４は、更に、社員クラス及び研究員クラスの双方に関連していた勤務クラスを、生成された抽象クラスに関連させる。その結果、（２）に示されるような、シンプル化及び明確化されたクラス図が得られる。
【００３６】
なお、汎化された抽象クラス（図６の（２）では社員クラス）のクラス名は、第２の実施の形態と同様にユーザによって入力されてもよい。又は、当該抽象クラスのサブクラス（社員クラス及び研究員クラス）のクラス名に共通部分が有れば、当該共通部分が自動的に抽象クラスのクラス名とされてもよい。
【００３７】
次に、第４の実施の形態について説明する。第４の実施の形態では第１の実施の形態と異なる点について説明する。第４の実施の形態において特に言及されない点については、第１の実施の形態と同様でもよい。
【００３８】
第４の実施の形態において、修正条件は、クラス名は異なるが、他のクラスとの関係性（関連）が同じである複数のクラスが存在することである。このようなクラス群は、本質的に同じ概念を示している可能性が高く、クラス図が対象とするシステムの冗長化又は煩雑化を招く可能性が高いからである。なお、他のクラスとの関係性（関連）が同じであるとは、当該他のクラスとの関連において多重度も一致することをいう。
【００３９】
図７は、第４の実施の形態におけるクラス図の修正例を示す図である。図７において、（１）は、修正前の状態を示し、（２）は、修正後の状態を示す。
【００４０】
（１）に示されるクラス図において、社員クラス及び所員クラスは、勤務クラス及び成果クラスに対する関係性において一致する。したがって、社員クラス及び所員クラスは、修正条件に該当する。よって、図３のステップＳ１０４において、社員クラス及び研究員クラスは、例えば、ハイライト表示される。
【００４１】
この場合、図３のステップＳ１０５において、修正部１４は、社員クラス及び所員クラスを一つに統合する。この際、社員クラス及び所員クラスのそれぞれに接続していた関係線は、統合後のクラスに接続される。その結果、（２）に示されるような、シンプル化、コンパクト化、及び明確化されたクラス図が得られる。
【００４２】
なお、統合後のクラスのクラス名（図７の（２）では「社員」）は、第２の実施の形態と同様に、ユーザによって入力されてもよい。また、統合後のクラスの属性は、統合前の各クラスの属性が統合されたものでよい。
【００４３】
次に、第５の実施の形態について説明する。第５の実施の形態では第１の実施の形態と異なる点について説明する。第５の実施の形態において特に言及されない点については、第１の実施の形態と同様でもよい。
【００４４】
第５の実施の形態において、修正条件は、多重度が１対１、又は１対０．．１（ゼロ又は１）の関係線が存在することである。このような関係線によって接続されるクラス同士は、同一で扱われるべき概念が無理に分割されている可能性が高く、クラス図が対象とするシステムの冗長化又は煩雑化を招く可能性が高いからである。
【００４５】
図８は、第５の実施の形態におけるクラス図の修正例を示す図である。図８において、（１）は、修正前の状態を示し、（２）は、修正後の状態を示す。
【００４６】
（１）に示されるクラス図において、社員クラスと社員番号クラスとの間の関係線の多重度は、１対１である。したがって、当該関係線は修正条件に該当する。よって、図３のステップＳ１０４において、当該関係線が、例えば、ハイライト表示される。又は、当該関係線で接続される社員クラス及び社員番号クラスが、更に、ハイライト表示されてもよい。
【００４７】
この場合、図３のステップＳ１０５において、修正部１４は、当該関係線で接続される二つのクラスを統合する。この際、修正部１４は、一方のクラス（社員番号クラス）を他方のクラス（社員クラス）の属性とする。いずれが属性とされるクラスであるかについては、ユーザに選択させてもよい。その結果、（２）に示されるような、シンプル化、コンパクト化、及び明確化されたクラス図が得られる。
【００４８】
次に、第６の実施の形態について説明する。第６の実施の形態では第１の実施の形態と異なる点について説明する。第６の実施の形態において特に言及されない点については、第１の実施の形態と同様でもよい。
【００４９】
第６の実施の形態において、修正条件は、関係線が集中しているクラスが存在することである。このようなクラスの存在は、クラス図が対象とするシステムの煩雑化を招く可能性が高いからである。また、このようなクラスは、コンピュータシステムのパフォーマンスのボトルネックとなる可能性や各種処理を複雑にする可能性が高いからである。なお、関係線の集中は、例えば、クラス図に含まれる各クラスの関係線の平均値との比較に基づいて判定されてもよい。例えば、当該平均値に対して１．５倍以上の関係線に接続されている状態が、関係線が集中している状態であると判定されてもよい。又は、クラス図における全関係線に対する割合によって、関係線の集中が判定されてもよい。例えば、全関係線のうちの３割以上の関係線に接続されている状態が、関係線が集中している状態であると判定されてもよい。
【００５０】
図９は、第６の実施の形態におけるクラス図の修正例を示す図である。図９において、（１）は、修正前の状態を示し、（２）は、修正後の状態を示す。
【００５１】
（１）に示されるクラス図において、勤務クラスには、全関係線が接続されている。したがって、勤務クラスは、修正条件に該当する。よって、図３のステップＳ１０４において、勤務クラスは、例えば、ハイライト表示される。
【００５２】
この場合、図３のステップＳ１０５において、修正部１４は、勤務クラスを２以上のクラスに分割する。その結果、（２）に示されるような、シンプル化及び明確化されたクラス図が得られる。（２）では、勤務クラスが勤務予定クラス及び勤務実績クラスの２つに分割されている。なお、分割後の各クラスのクラス名は、ユーザによって入力されてもよい。また、分割前の勤務クラスの各属性が、分割後のいずれのクラスの属性となるかについても、ユーザに選択させてもよい。更に、分割前の勤務クラスの関係線が、分割後のいずれのクラスに接続されるかについても、ユーザに選択させてもよい。
【００５３】
次に、第７の実施の形態について説明する。第７の実施の形態では第１の実施の形態と異なる点について説明する。第７の実施の形態において特に言及されない点については、第１の実施の形態と同様でもよい。
【００５４】
第７の実施の形態において、修正条件は、複数のシステムが有る場合において、異なるシステムに属するクラス間の関係線の数が閾値以上であることである。異なるシステムに属するクラス間の関係線が多い状態は、クラス図が対象とするシステムの煩雑化を招く可能性が高いからである。また、このような関係線が多い場合、システムにおいて、情報の管理場所が間違っている可能性が高いからである。なお、閾値は、異なるシステムに属するクラス間の関係線の平均値に基づいて設定されてもよい。例えば、当該平均値に対して１．５倍が、閾値とされてもよい。又は、クラス図における全関係線に対する割合によって、閾値が設定されてもよい。
【００５５】
図１０は、第７の実施の形態におけるクラス図の修正例を示す図である。図１０において、（１）は、修正前の状態を示し、（２）は、修正後の状態を示す。
【００５６】
（１）に示されるクラス図において、システムＢに属する勤務クラスと、システムＡに属する各クラスとの間の関係線は、クラス図の全関係線に相当する。したがって、システムＢに属する勤務クラスと、システムＡに属する各クラスとの間の関係線は、修正条件に該当する。よって、図３のステップＳ１０４において、これらの関係線は、例えば、ハイライト表示される。なお、図１０では、システムＡとシステムＢとのみが示されているが、これら以外のシステムが存在する場合、各システム間の関係線の数の平均値が閾値とされてもよい。
【００５７】
この場合、図３のステップＳ１０５において、修正部１４は、システム間の関係線が少なくなるように根本原因となるクラスを別システム移動する。例えば、勤務クラスをクラスＢに移動する。その結果、（２）に示されるような、シンプル化されたクラス図が得られる。
【００５８】
なお、根本原因となるクラス（移動対象とするクラス）としては、例えば、修正条件に該当する関係線に接続される各クラスが属するシステムの集合の中で、所属するクラスの数が相対的に少ないシステムに属するクラスが修正部１４によって自動的に選択されてもよい。又は、ユーザによって選択されてもよい。
【００５９】
また、クラスが属するシステムは、クラスに対する付加情報として各クラスに対して付加される。
【００６０】
次に、第８の実施の形態について説明する。第８の実施の形態では第１の実施の形態と異なる点について説明する。第８の実施の形態において特に言及されない点については、第１の実施の形態と同様でもよい。
【００６１】
第８の実施の形態において、修正条件は、直列に閾値以上の階層の継承関係が存在することである。このような継承関係は、クラス図が対象とするシステムの冗長化又は煩雑化を招き、改造開発等において何層目に手を入れるべきか誤りを生じる原因になる可能性が高いからである。なお、閾値は、例えば、クラス図に含まれる継承関係の階層の平均値に基づいて設定されてもよい。例えば、当該平均値に対して１．５倍の値が、閾値とされてもよい。
【００６２】
図１１は、第８の実施の形態におけるクラス図の修正例を示す図である。図１１において、（１）は、修正前の状態を示し、（２）は、修正後の状態を示す。
【００６３】
（１）に示されるクラス図において、社員クラスをルートクラスとする継承関係の階層数は、４である。４が、図示されていない他の階層数をも含む平均値に比べて非常に多い場合、当該継承関係は、修正条件に該当する。この場合、図３のステップＳ１０４において、例えば、当該継承関係を示す線がハイライト表示される。
【００６４】
また、図３のステップＳ１０５において、修正部１４は、サブクラスを削除して階層数を減らす。例えば、平均以上の階層に属するサブクラスが修正部１４によって強制的に削除されてもよい。又は、削除対象とするサブクラスがユーザによって選択されてもよい。その結果、（２）に示されるような、シンプル化及びコンパクト化されたクラス図が得られる。
【００６５】
次に、第９の実施の形態について説明する。第９の実施の形態では第１の実施の形態と異なる点について説明する。第９の実施の形態において特に言及されない点については、第１の実施の形態と同様でもよい。
【００６６】
第９の実施の形態において、修正条件は、直接関連する（関係線によって接続される）クラス間において、同一名の属性が存在することである。このようなクラスの存在は、同一機能が重複し設計の複雑化を招く可能性が高く、クラス図が対象とするシステムの冗長化及び煩雑化を招く可能性が高いからである。
【００６７】
図１２は、第９の実施の形態におけるクラス図の修正例を示す図である。図１２において、（１）は、修正前の状態を示し、（２）は、修正後の状態を示す。
【００６８】
（１）に示されるクラス図において、社員クラスと名簿クラスとは関係線によって接続され、かつ、社員クラスと名簿クラスとの属性は、氏名、所属名について重複する。したがって、社員クラス及び名簿クラスは、修正条件に該当する。よって、図３のステップＳ１０４において、社員クラス及び名簿クラスにおいて重複する属性の属性名は、例えば、ハイライト表示される。
【００６９】
この場合、図３のステップＳ１０５において、修正部１４は、修正条件に該当する２つのクラスのいずれか一方から当該属性名を削除する。図１２の場合、例えば、名簿クラスの氏名及び所属名が削除される。その結果、（２）に示されるような、シンプル化、コンパクト化、及び明確化されたクラス図が得られる。なお、属性名が削除されるクラスは、例えば、ユーザによって選択されてもよい。
【００７０】
次に、第１０の実施の形態について説明する。第１０の実施の形態では第１の実施の形態と異なる点について説明する。第１０の実施の形態において特に言及されない点については、第１の実施の形態と同様でもよい。
【００７１】
第１０の実施の形態において、修正条件は、近い関係を持つが名称の異なるクラス間において、クラスの持つ意味（機能）が全く同じか一部同じであること（クラス同士が正規化されていないこと）である。このようなクラス群の存在は、機能の重複によってシステムの複雑化を招く可能性が高く、クラス図が対象とするシステムの冗長化又は煩雑化を招く可能性が高いからである。
【００７２】
図１３は、第１０の実施の形態におけるクラス図の修正例を示す図である。図１３において、（１）は、修正前の状態を示し、（２）は、修正後の状態を示す。
【００７３】
（１）に示されるクラス図において、正社員クラス及び派遣社員クラスがこのようなクラス群に該当すれば、正社員クラス及び派遣社員クラスは修正条件に該当する。また、正社員用入退室管理クラス及び派遣社員用入退室管理クラスがこのようなクラス群に該当すれば、正社員用入退室管理クラス及び派遣社員用入退室管理クラスは修正条件に該当する。
【００７４】
したがって、この場合、図３のステップＳ１０４において、正社員クラス及び派遣社員クラス、並びに正社員用入退室管理クラス及び派遣社員用入退室管理クラスは、例えば、ハイライト表示される。なお、修正条件に該当するクラスは、例えば、クラス名の重複部分に基づいて判定されてもよい。例えば、クラス名の半分以上が一致するクラス群は、修正条件に該当すると判定されてもよい。又は、修正条件に該当するクラスがユーザによって選択されてもよい。
【００７５】
また、この場合、図３のステップＳ１０５において、修正部１４は、修正条件に該当するクラス群を正規化して定義し直す。例えば、修正部１４は、修正条件に該当するクラス群に対する抽象クラスを生成し、当該クラス群を抽象クラスに対するサブクラスとする。この際、抽象クラスのクラス名は、当該クラス群の各クラスのクラス名の重複部分に基づいて自動的に生成されてもよいし、ユーザによって入力されてもよい。その結果、（２）に示されるような、シンプル化、コンパクト化、及び明確化されたクラス図が得られる。
【００７６】
次に、第１１の実施の形態について説明する。第１１の実施の形態では第１の実施の形態と異なる点について説明する。第１１の実施の形態において特に言及されない点については、第１の実施の形態と同様でもよい。
【００７７】
第１１の実施の形態において、修正条件は、ノート機能による補足情報が付加されているクラスが存在することである。このようなクラスは、属性（機能）が不足しており、システムの機能を手作業で補っている部分に該当する可能性が高く、クラス図が対象とするシステムの煩雑化を招く可能性が高いからである。
【００７８】
図１４は、第１１の実施の形態におけるクラス図の修正例を示す図である。図１４において、（１）は、修正前の状態を示し、（２）は、修正後の状態を示す。
【００７９】
（１）に示されるクラス図において、勤務クラスには、ノート機能による補足情報が付されている（図中では吹き出しによって補足情報が表現されている）。したがって、勤務クラスは、修正条件に該当する。よって、図３のステップＳ１０４において、勤務クラスは、例えば、ハイライト表示される。
【００８０】
この場合、図３のステップＳ１０５において、修正部１４は、補足情報に対応する属性を、当該補足情報に係るクラスに追加し、当該補足情報を削除する。これは、手作業として不明確だった機能がシステム機能として明確化されることを意味する。その結果、（２）に示されるような、明確化されたクラス図が得られる。すなわち、（２）では、勤務クラスに対して承認属性が追加され、勤務クラスに対する補足情報が削除されている。なお、補足情報に対応する属性の属性名は、ユーザによって入力されてもよい。
【００８１】
なお、第１〜第１１の実施の形態は、相互に排他的又は選択的な関係ではないため、各実施の形態が一緒に実施されてもよい。具体的には、図３のステップＳ１０２では、各実施の形態の修正条件について、該当箇所の有無が判定されてもよい。
【００８２】
上述したように、上記各実施の形態によれば、概念データモデルで表現したシステムに存在する冗長性又は煩雑性の除去を支援することができる。その結果、シンプル化、コンパクト化、又は明確化されたクラス図を得ることができる。このようなクラス図によれば、既存のシステムの改善点の発見の容易化を期待することができ、設計及び開発作業の手戻りの削減や、システムの品質の向上等を期待することができる。
【００８３】
なお、修正箇所判定部１２は、判定部の一例である。修正条件は、所定の条件の一例である。
【００８４】
以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【符号の説明】
【００８５】
１０          概念データモデル修正支援装置
１１          クラス図入力部
１２          修正箇所判定部
１３          出力部
１４          修正部
１５          クラス図記憶部
１００        ドライブ装置
１０１        記録媒体
１０２        補助記憶装置
１０３        メモリ装置
１０４        ＣＰＵ
１０５        インタフェース装置
１０６        表示装置
１０７        入力装置
Ｂ            バス
【図１】
2018041363.tif 000003
【図２】
2018041363.tif 000004
【図３】
2018041363.tif 000005
【図４】
2018041363.tif 000006
【図５】
2018041363.tif 000007
【図６】
2018041363.tif 000008
【図７】
2018041363.tif 000009
【図８】
2018041363.tif 000010
【図９】
2018041363.tif 000011
【図１０】
2018041363.tif 000012
【図１１】
2018041363.tif 000013
【図１２】
2018041363.tif 000014
【図１３】
2018041363.tif 000015
【図１４】
2018041363.tif 000016