モジュール関連図と影響範囲調査
はじめに
連載の前半で、現代のシステム開発は新規よりも保守・運用に多くの時間を取られているという問題に直面していることをお話しました。どうすれば保守・運用にかかるメンテナンスコストを低減して、もっと新しいことに取り組めるでしょうか。その実現に向けた取り組みの1つが影響範囲調査の効率化です。今回は昔からあるCRAD図による調査方法と、ちょっとCADらしい影響範囲調査について解説します。
モジュール関連図
前回、イベントドリブン処理の構成を図示しました。この関係をそのまま設計図として表現するのが「モジュール関連図」です。この図は、これまで説明してきたコントロール定義、イベント定義、ロジック定義の情報をもとにコンピュータ(CAD)が自動作画したものです。例えば画面1は「受注一覧」画面のモジュール関連図ですが、機能がどのようにモジュール分割されていて、どのように処理するかがビジュアルに表示されています。まずは、このモジュール関連図について説明しましょう。
画面1：モジュール関連図
(1)コントロールとイベント
画面1の左の箱は、「受注一覧」画面で発生するイベントの一覧です。箱の中にある各イベントは、第8回で説明した「イベント定義」の定義情報(画面2)から作られています。例えば、画面1の一番下の「削除ボタン.クリック時」から「受注削除」モジュールに矢印が引かれている部分は、イベント定義で「削除ボタン」コントロールの「クリック時」というイベントで「受注削除」というロジックを呼び出すことを定義した情報で描画されています。
画面2：イベント定義
画面1のロジック「受注削除」からテーブル「受注データ」と「受注データ明細」に矢印が接続されているのは、ロジックのインターフェースでアクション欄に定義した情報(画面3)を使っています。アクション欄の操作としてDを選択していますが、これはDelete(削除)を行うという意味で、この後に説明するCRUD図を意識しています。
この定義情報が画面1のモジュール関連図にも反映され、「更新のみ」の矢印を使って2つのテーブルを削除することが表現されています。なお、CADではテーブルの色でSelectかDeleteかそれ以外かも表現しています。
画面3：ロジックインターフェース
ExcelやWordで書いた設計書の情報は単なる文字情報なので、読む以外に加工も活用もできません。CADはコントロールもイベントもモジュールも、さらにそれらの関連情報もすべてパーツとして管理するので、このようなモジュール関連図を自動生成できるわけです。
(2)CRUD図
保守や機能追加などによりシステムに変更を加えたとき、ある個所を修正したときに思わぬところに影響が及んで大きな問題になることがあります。このようなトラブルを避けるため、変更を加える前に影響範囲調査を行いますが、システムが大規模になればなるほどこの作業に多くの時間がかかってしまい、メンテナンスコストを跳ね上げます。
「なんとかパッと影響個所を把握できないか」ということで作られているのがCRUD図です。CRUD図はロジックやプロセスなど処理を行うものを縦、画面を横に並べたマトリクスです。そして、ロジックがテーブルに対して行う操作をCRUDの文字を使って表わします(図1)。
図1：CRUD図
CRUD(クラッド)のそれぞれの文字は次の操作を意味しています。
C：Create(データの作成)
R：Read(データの読出)
U：Update(データの更新)
D：Delete(データの削除）
テーブルに対する操作なので、それぞれをSQLに当てはめると、CRUDの順番にInsert、Select、Update、Deleteになります(私はこちらの方がしっくりきます)。
例えば、ロジック「受注更新」は「受注データ」と「受注明細」の2つのテーブルに対して、CとUの文字になっています。これは、この2つのテーブルにデータの挿入と更新を行うことを意味しています。
これ、見方を変えてテーブルの方から見るとどうなるでしょうか。例えば、テーブル「受注データ」の縦列を見てみると、「受注検索」「受注更新」「受注削除」の3つのロジックから操作されていることがわかります。もし、機能変更が生じて「受注データ」テーブルに列を追加することになった場合、この3つのロジックだけ影響がないかを調べれば事足りるようになるわけです。
CRUD図の効能は、運用フェーズの影響範囲調査だけではありません。設計フェーズでCRUD図を作成し、モジュール間の関連を分析して設計に役立てることもできます。例えば、図1では「受注データ」「受注明細」を更新(U)するのは「受注更新」だけであることがわかります。そうではなく、いろいろなモジュールから更新されているようなら、前回解説したモジュール分割がうまくできていないか、MVCモデルの概念が実装されてない恐れがあります。また、「顧客データ」は「得意先名取得」と「受注検索」モジュールから参照(R)されていますが、このように参照(Select）するモジュールを把握できればインデックスを作成するときにも役立ちます。
なお、MVCモデルとはシステムをModel(ビジネスロジック)とView(表示や入出力)とController(ModelとViewの橋渡し)という3つに役割分担させて実装する手法のことです。昔はいろいろな画面から直接データを更新するシステムもありましたが、最近では画面はView機能に特化し、データ更新はビジネスロジックが行うというように分担する構造が取られています。さらに「このテーブルを更新するのはこのロジックだけ」というように、更新するロジックを絞ってメンテナンス性を高めることもやりやすくなっています。
画面1の例は「受注一覧」という単機能のモジュール関連図ですが、システムのすべての機能を統合して見るとCRUD図を生成できます。画面4はCADからExcel出力したCRUD図で、ここではロジック単位でなく画面単位にまとめています。このようなCRUD図を作成するため、ロジックのインターフェースでテーブルに対する操作欄にはCRUDという表現を使っているわけです。
画面4：CRUD図(CADからExcel出力)
- 先輩：麻里ちゃん。今日はまたずいぶんと難しい顔しているね?
- 麻里：あ、先輩。実はCRUD図で論理削除をUにするかDにすべきか悩んでいて…
- 先輩：なるほど。それは確かに悩むポイントだね。
- 麻里：やっぱり削除フラグを立てるという更新処理だからUが良いのかなぁ。
- 先輩：まあ、それも一理あるけど、CRUD図をどう役に立てるかを考えてみようか。
- 麻里：ええと、データがどの処理で作成されたり更新されたりするのかをパッと分かるようにするため…ですよね?
- 先輩：で、そういう観点だと?
- 麻里：もし、論理削除を更新にすると、データがどこから削除されるのかがわからなくなる。ということは、やっぱりDにした方が良さそうですね。
- 先輩：うん、僕もそう思う。ただ、僕はそもそも論理削除を使わない派なんだけどね。
- 麻里：え、でも社員データや部門データとかは論理削除じゃないと困りませんか?
- 先輩：それってそもそも削除じゃないと思うんだ。社員の場合は削除フラグじゃなくて「退職フラグ」、部門の場合は「利用フラグ」か「適用期間」を持つべきだよ。
- 麻里：間違って削除してしまったのを戻したいときは?
- 先輩：そのような操作を想定するべきデータかどうかにもよるけど、本当に必要なら確かに削除フラグはアリかも。でも、やっぱりナシかな。ログから戻せるようにする方法もあるし。
- 麻里：誰がいつ削除したか証跡を残しておきたいときは?
- 先輩：それもログで追えれば良い。
- 麻里：ふ～ん、先輩って異性には未練がましいとこあるけど、削除に関してはバッサリなんですね。
- 先輩：おいおい、どこが未練がましいんだよ～。
(3)クロスリファレンス
せっかく、モジュール関連情報がパーツで管理されているので、もっと柔軟に検索しようということで用意したのがクロスリファレンスです。図1のCRUD図がロジックとテーブルの単方向の関係を表すのに対し、クロスリファレンスは画面、帳票、バッチ、テーブル、ビュー、ロジックそれぞれの双方向の関係をアドホックに検索できます。
①参照先
具体的な画面で説明しましょう。画面5はクロスリファレンス機能により「受注一覧」画面が参照しているモジュールを3階層まで表示しています。この図を見れば、「受注一覧」画面がどのロジックを利用しており、それぞれのロジックがどのテーブルやビューをCRUD操作しているのかが一目でわかります。例えば「受注一覧画面」を変更する場合にこの機能を使って関連するモジュールを一覧すれば、どこを変更しなければならないか一発で当たりを付けることができます。
画面5：クロスリファレンス画面(参照先)
②呼出し元
クロスリファレンスの特徴は双方向です。こちらも画面を使って説明しましょう。画面6はタブを「呼び出し元」に切り替えて、今度はテーブル「受注データ」を元に逆検索したものです。これを見ると、受注データがどのロジックからCRUD操作されており、それらを呼び出している親機能(画面やバッチや上位ロジック)が何かということもわかります。例えば「受注データ」の列を変更する場合、このように逆検索することで、どこに影響がありそうかを簡単に調査できます。
画面6：クロスリファレンス画面(呼び出し元)
おわりに
今回はモジュールの関連をビジュアルに理解できる「モジュール関連図」と、それをシステム全体に統合して生成する「CRUD図」について説明しました。また、CADのクロスリファレンス機能により双方向に影響範囲調査を行える仕組みも参考になれば幸いです。クロスリファレンスはCADならではの機能ですが、WordやExcelの設計書でも、どうすれば大きな工数をかけずに影響範囲調査を行えるか仕組みを考えておくことは重要です。
