(57)【要約】【課題】概念データモデルの理解の容易化を支援すること。【解決手段】概念データモデル編集プログラムは、業務に関する概念データモデルを表現するクラス図と、前記業務における各作業の順序情報とを入力する入力部と、前記クラス図において前記各作業に対応するクラスが、前記順序情報が示す順序で配置されるように前記クラス図を編集する編集部と、前記編集部によって編集されたクラス図を出力する出力部と、としてコンピュータを機能させる。【選択図】図２
2018041364.tif 000002
【特許請求の範囲】
【請求項１】
業務に関する概念データモデルを表現するクラス図と、前記業務における各作業の順序情報とを入力する入力部と、
前記クラス図において前記各作業に対応するクラスが、前記順序情報が示す順序で配置されるように前記クラス図を編集する編集部と、
前記編集部によって編集されたクラス図を出力する出力部と、
としてコンピュータを機能させることを特徴とする概念データモデル編集プログラム。
【請求項２】
前記編集部は、前記順序情報が示す順序が、２次元空間における一方の次元に割り当てられ、前記各作業に対応するクラスに関連する他のクラスが、前記２次元空間における他方の次元に配置されるように前記クラス図を編集する、
ことを特徴とする請求項１記載の概念データモデル編集プログラム。
【請求項３】
前記編集部は、前記各作業に対応するクラスと、前記各作業に関連する他のクラスとを色分けする、
ことを特徴とする請求項２記載の概念データモデル編集プログラム。
【請求項４】
前記入力部は、前記業務に関するシステムと前記各作業に対応するクラスとの対応関係を示す情報を入力し、
前記編集部は、前記対応関係を示す枠を前記クラス図に追加する、
ことを特徴とする請求項１乃至３いずれか一項記載の概念データモデル編集プログラム。
【請求項５】
前記入力部は、前記業務に関するシステムと前記各作業に対応するクラスとの対応関係を示す情報を入力し、
前記編集部は、前記対応関係に基づいて、前記各作業に対応するクラスのステレオタイプとして当該クラスに対応するシステムの名前を追加する、
ことを特徴とする請求項１乃至３いずれか一項記載の概念データモデル編集プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概念データモデル編集プログラムに関する。
【背景技術】
【０００２】
大規模ソフトウェアについては、仕様が複雑化するため、仕様を分かりやすく表現する文書の作成が困難である。したがって、ソフトウェアの改良等を行おうとした場合に、仕様の理解が困難となり、改良作業等の支障となっている。
【０００３】
そこで、概念データモデルを利用してソフトウェアの仕様を表現することで、仕様の理解の容易化や、関係者間での意識の共有の促進等を期待することができる。その結果、概念データモデルをベースに関係者での議論が促進され、改良前のソフトウェアにおける問題点の洗い出しや、当該問題点の解決方法の検討がはかどることが期待できる。
【０００４】
データモデリング方法に関する従来技術は有るが（例えば、特許文献１）、概念データモデルを使った関係者での意識共有のための技術は見当たらない。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１１−１５４６５３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、概念データモデルを見慣れていない者にとって、概念データモデルは難解である。したがって、概念データモデルのみを使って、関係者に対してシステムの主要な要件を説明したり、関係者からシステムの問題点を聞き出したり、システムの仕様について合意を得たりすることが困難であった。
【０００７】
本発明は、上記の点に鑑みてなされたものであって、概念データモデルの理解の容易化を支援することを目的とする。
【課題を解決するための手段】
【０００８】
そこで上記課題を解決するため、概念データモデル編集プログラムは、業務に関する概念データモデルを表現するクラス図と、前記業務における各作業の順序情報とを入力する入力部と、前記クラス図において前記各作業に対応するクラスが、前記順序情報が示す順序で配置されるように前記クラス図を編集する編集部と、前記編集部によって編集されたクラス図を出力する出力部と、としてコンピュータを機能させる。
【発明の効果】
【０００９】
概念データモデルの理解の容易化を支援することができる。
【図面の簡単な説明】
【００１０】
【図１】本発明の実施の形態における概念データモデル編集装置のハードウェア構成例を示す図である。
【図２】本発明の実施の形態における概念データモデル編集装置の機能構成例を示す図である。
【図３】概念データモデル編集装置が実行する処理手順の一例を説明するためのフローチャートである。
【図４】クラス図の一例を示す図である。
【図５】作業一覧の一例を示す図である。
【図６】作業フローの一例を示す図である。
【図７】編集結果としてのクラス図の第１の例を示す図である。
【図８】編集結果としてのクラス図の第２の例を示す図である。
【図９】編集結果としてのクラス図の第３の例を示す図である。
【発明を実施するための形態】
【００１１】
以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態における概念データモデル編集装置のハードウェア構成例を示す図である。図１の概念データモデル編集装置１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、インタフェース装置１０５、表示装置１０６、及び入力装置１０７等を有する。
【００１２】
概念データモデル編集装置１０での処理を実現するプログラムは、ＣＤ−ＲＯＭ等の記録媒体１０１によって提供される。プログラムを記憶した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。
【００１３】
メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従って概念データモデル編集装置１０に係る機能を実現する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。表示装置１０６はプログラムによるＧＵＩ（Graphical User Interface）等を表示する。入力装置１０７はキーボード及びマウス等で構成され、様々な操作指示を入力させるために用いられる。
【００１４】
図２は、本発明の実施の形態における概念データモデル編集装置の機能構成例を示す図である。図２において、概念データモデル編集装置１０は、入力部１１、編集部１２、及び出力部１３等を有する。これら各部は、概念データモデル編集装置１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。概念データモデル編集装置１０は、また、クラス図記憶部１４を利用する。クラス図記憶部１４は、例えば、補助記憶装置１０２、又は概念データモデル編集装置１０にネットワークを介して接続可能な記憶装置等を用いて実現可能である。
【００１５】
入力部１１は、処理の開始時において、クラス図記憶部１４からクラス図を読み込むと共に、作業一覧及び作業フローの入力を、例えば、入力装置１０７を介してユーザから受け付ける。但し、作業一覧及び作業フローも、予め、補助記憶装置１０２等に記憶されていてもよい。
【００１６】
クラス図記憶部１４には、業務に関するコンピュータシステム（以下、単に「システム」という。）のソフトウェア設計のためのデータ構造を抽象化して表現した概念データモデルを示すクラス図が記憶されている。当該クラス図は、当該システムの仕様を満たすものであるとする。なお、当該システムは、複数のシステムから構成されてもよい。
【００１７】
作業一覧とは、当該業務において行われる主要な作業の一覧情報であり、各作業の名前（以下、「作業名」という。）や、各作業に対応するシステムの名前（以下、「システム名」という。）等が含まれる。
【００１８】
作業フローとは、作業一覧に係る各作業の実行順序（作業の時系列順）を示す情報（順序情報）である。例えば、作業名が実行順に配列されたデータが、作業フローであってもよい。
【００１９】
編集部１２は、作業一覧及び作業フローに基づいて、クラス図を編集する。例えば、編集部１２は、クラス図において各作業に対応するクラスが、作業フローが示す順序で配置されるようにクラス図を編集する。
【００２０】
出力部１３は、編集部１２による編集結果を出力する。例えば、編集結果が表示装置１０６に表示される。
【００２１】
以下、概念データモデル編集装置１０が実行する処理手順について説明する。図３は、概念データモデル編集装置が実行する処理手順の一例を説明するためのフローチャートである。
【００２２】
ステップＳ１０１において、入力部１１は、クラス図記憶部１４からクラス図を読み込む。
【００２３】
図４は、クラス図の一例を示す図である。クラス図は、例えば、ＵＭＬ（Unified Modeling Language）等によって記述されている。なお、この時点において、クラス図における各クラスの配置位置は任意である。
【００２４】
続いて、入力部１１は、作業一覧及び作業フローの入力を受け付ける（Ｓ１０２）。
【００２５】
図５は、作業一覧の一例を示す図である。図５に示されるように、作業一覧は、主要な作業ごとに、作業名、システム名及び作業内容等を含む。システム名は、作業に対応するシステムのシステム名である。作業に対応するシステムとは、例えば、当該作業において利用されるシステム、又は当該作業を示すデータを管理するシステムである。すなわち、作業は、システムにおいてはデータにモデル化されて管理される。このように、作業一覧は、作業とシステムとの対応関係を示す。作業内容は、作業の内容を示す説明文である。なお、図５では、便宜上、作業一覧が表形式によって表現されているが、ＣＳＶ（Comma Separated Values）やＸＭＬ（eXtensible Markup Language）形式等、他の形式によって作業一覧が実装されてもよい。
【００２６】
また、図６は、作業フローの一例を示す図である。図６に示されるように、作業フローは、作業一覧に含まれる作業名が、作業の実行順に配列されたデータである。なお、作業一覧に対して作業フローが含まれてもよい。例えば、作業一覧において、各作業名に対して、作業の実行順を示す順番が付与されてもよい。
【００２７】
続いて、編集部１２は、作業一覧及び作業フローに基づいてクラス図を編集する（Ｓ１０３）。続いて、出力部１３は、編集部１２による編集結果を出力する（Ｓ１０４）。
【００２８】
図７は、編集結果としてのクラス図の第１の例を示す図である。図７においては、図４に示したクラス図に含まれるクラスのうち、主要な作業に対応するクラス（予算計画クラス、契約実施順部クラス、契約金管理部クラス、契約クラス、受け取りクラス、支払決定クラス）が、左側に寄せられ、作業フローの順番で垂直方向に配置されている。また、作業に対応するクラス間には、作業の流れ（順番）を分かりやすく示すために、矢印ａ１〜ａ５が配置（追加）されている。なお、編集部１２は、主要な作業に対応するクラスを、クラス名と作業名との一致に基づいて判定する。すなわち、本来、概念データモデルは、静的なデータ構造を表現するものであるが、本実施の形態では、作業の順番をも表現することが可能となっている。
【００２９】
また、編集によって、主要な作業に対応するクラスに関連する他のクラス（例えば、補足的な作業に対応するクラス）は、主要な作業に対応するクラスの水平方向に（右側に）配置されている。
【００３０】
但し、主要な各クラスの作業順が、水平方向に割り当てられ、当該各クラスに関連する他のクラスが垂直方向に割り当てられてもよい。すなわち、クラス図が配置される２次元空間において、一方の次元に対して各作業の順序が割り当てられ、他方の次元に対して当該各作業に関連する他のクラスが割り当てられればよい。
【００３１】
また、編集によって、システムごとに、当該システムに関連するクラスが、当該システムのシステム名が付与された矩形の枠で囲まれている。そうすることで、各クラスが関連するシステムが分かりやすく示されている。なお、編集部１２は、各クラスとシステムとの関連を、作業一覧に基づいて判定する。
【００３２】
更に、編集によって、主要な作業に対応するクラスと、そうでない他のクラスとが色分けされている。なお、図７では、網掛けの違いによって色分けが表現されている。但し、主要な作業に対応するクラスがハイライト表示（強調表示）されることで、他のクラスとの区別が明確化されてもよい。
【００３３】
なお、図７では、システムごとの枠毎に、当該システムに含まれるクラスに対応する作業を誰が行うのかを示す担当情報ｐ１〜ｐ４も示されている。例えば、担当情報ｐ１では、予算計画が、予算管理担当者の作業であることが示されている。斯かる担当者の情報は、例えば、編集結果の出力後において、ユーザによって入力されてもよい。又は、作業一覧に含まれていてもよい。
【００３４】
図７に示されるようなクラス図（概念データモデル）によれば、データ構造のみならず、業務における作業の順番等も表現可能となっている。したがって、作成すべき資料を、例えば、概念データモデルに限定することができる。その結果、資料作成作業の負担を軽減することができると共に、理解すべき資料の量を削減することもできる。一方、従来は、様々な資料（例えば、業務フロー図、業務一覧、システム一覧、システム設計図）を用いて、現行システムの主要要件の説明を行い、現場の関係者から問題を聞きだしたり、合意を得たりしていた。そのため、様々な資料の作成作業が発生していた。
【００３５】
また、本実施の形態によれば、１つの資料（概念データモデル）を用いて、上記の様々な資料を用いた場合と同様の議論が可能となるため、要件合意や問題点抽出の際の論点が明確となり、的を得た議論ができる。一方、従来は、業務担当者とは業務フロー等で議論し、システム設計者とは設計書等（概念データモデル図を含む）で議論していた。
【００３６】
また、概念データモデル図は、本来、静的なデータ構造を表す図であるが、本実施の形態により、誰がどの業務を実施しているのかや、業務の流れなどの動的な情報も表すことができるため、意味が分かりやすくなり、概念データモデル図を熟知していない一般の人でもそれを見て理解しやすくなる。その結果、開発の効率が上がり、上位工程で混入するバグ（主に仕様バグ等）を開発の早期の段階で検出できるため、最終工程でのバグの検出による手戻りを削減することができる。
【００３７】
また、一般的に、従来法では、要求や要件の確認は、作業プロセス（作業手順）によって行なうことが多いが、それを理解するだけではシステム上の機能との不整合を拾い出すことが難しい。一方、ソフトウェアシステム（主にＲＤＢＭＳ）では、データモデル構造（スキーマ）をベースにシステム化が実装される。従来法では、現場（主に業務を実施する現場）への要求や要件のヒアリングにおいては、作業プロセス（業務フローなど）によって実施され、データモデル構造の検討とは独立に実施されてきた。従って、ヒアリング後に、得られた要件をデータモデル構造上に変換して表現する必要があり、ヒアリング時の抜け漏れや、変換の作業が発生していた。
【００３８】
本実施の形態によれば、１枚の図（概念データモデル図）のみを使って、このようなヒアリング時の抜け漏れを減らすとともに、無駄な変換作業を減らすことができる。
【００３９】
また、実装すべきデータモデルの構造を要点のみ俯瞰した「概念データモデル」を用いることによって、「概念スキーマ⇒論理スキーマ⇒物理スキーマ」の実装段階における初期段階において、早く改善点や修正点を明確化できるため、開発の手戻りを防ぐことができる。
【００４０】
なお、例えば、図８に示されるような編集結果が得られるようにしてもよい。図８は、編集結果としてのクラス図の第２の例を示す図である。図８では、図７に示したクラス図に対して、更に、ノートｎ１が付加されている。このように、ノートｎ１により、補足情報の付加が可能とされてもよい。補足情報は、例えば、ユーザによって入力されてもよいし、クラスごとに補足情報を示すデータが、入力情報として入力されてもよい。後者の場合、編集部１２が、ステップＳ１０３において、補足情報が付加されているクラスに対して、補足情報を示すノートを付加してもよい。
【００４１】
また、上記では、各クラスが属するシステムが、システムの枠によって囲まれる例を示したが、ＵＭＬ（Unified Modeling Language）のステレオタイプによって、各クラスが属するシステムが表現されてもよい。
【００４２】
図９は、編集結果としてのクラス図の第３の例を示す図である。図９では、予算計画クラスと業務種別クラスとが抜き出されて示されている。これらのクラスには、ステレオタイプとして、システム名が付加されている。すなわち、編集部１２は、各クラスに対応するシステム名を、ステレオタイプとして各クラスに追加する。
【００４３】
以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【符号の説明】
【００４４】
１０          概念データモデル編集装置
１１          入力部
１２          編集部
１３          出力部
１４          クラス図記憶部
１００        ドライブ装置
１０１        記録媒体
１０２        補助記憶装置
１０３        メモリ装置
１０４        ＣＰＵ
１０５        インタフェース装置
１０６        表示装置
１０７        入力装置
Ｂ            バス
【図１】
2018041364.tif 000003
【図２】
2018041364.tif 000004
【図３】
2018041364.tif 000005
【図４】
2018041364.tif 000006
【図５】
2018041364.tif 000007
【図６】
2018041364.tif 000008
【図７】
2018041364.tif 000009
【図８】
2018041364.tif 000010
【図９】
2018041364.tif 000011