ロジック処理の設計標準化
はじめに
今回はロジック処理を記述するフォーマットについて解説します。これまでと同様に、標準フォーマットの例は設計書作成CAD「SI Object Browser Designer(OBDZ)」を用いますが、Excelなどで設計書を作成していても標準化の考え方は一緒なので、自社でお使いの設計書テンプレートと比較しながらお読みください。
イベントドリブン処理の構成
前回、麻里ちゃんがイベントドリブン(イベント駆動)型のアプリケーションについて質問していましたが、そのモジュール構成を図で表すと図1のようになります。画面Aに配置されたテキストボックス(textbox)やボタン(button)などのコントロールで、値を変えたり(OnChang)、クリックしたり(OnClick)するイベントをきっかけに処理が行われるのがイベントドリブンでしたね。前回は、図1の左側の「コントロール」と「イベント」の標準化がテーマでしたが、今回は処理内容を記述する右側の「ロジック」について解説します。
図1：イベントドリブン処理の構成
モジュール化
モジュール化はソフトウェア設計において非常に重要なので、今回はここから入っていきます。
(1)モジュール分割
ソフトウェアは、何かを行うために書かれた“コンピュータに対する手順書”ですが、通常、複数の機能や処理が複雑に組み合わされています。この大きなソフトウェアの塊を機能やデータごとに小さな部品に分割し、独立した形で扱えるように構成して、それらを組み合わせて目的の処理を実現することをモジュール化(モジュール分割)と言います。
例を挙げて説明しましょう。期末に「部門に与えられるインセンティブを計算し、その金額を営業員の目標売上達成度をもとに配分して賞与にプラスする」という処理を行うため、そのソフトウェアを作ることになったとしましょう。これを1つのモノシリック(一枚岩)なソフトウェアで記述することは可能です。プログラミングを覚えたてのプログラマーに依頼すれば、何も考えずにそう作るでしょう。
しかし、経験を積んだプログラマーにお願いすると、感覚的にそう作るのは気持ち悪いと感じ、例えば図2のように
- 部門別売上集計
- 社員別売上集計
- 部門インセンティブ計算
- 営業インセンティブ計算
- 賞与計算
(2)モジュール分割の粒度
「モジュールをどの粒度まで分割すれば良いか」は一概に言えません。小さくすれば個々のモジュールはシンプルになり汎用性も増しますが、その分インターフェースが複雑になったり、モジュール管理が大変になったりします。“いい感じに”モジュール分割するスキルは、車の運転やスキーの技術と同じです。練習と経験で自然に身につくものであり、大まかな理論はあるものの「こうすれば良い」と絶対法則で示せるものではありません。
では「何の粒度で分割するか」という点に関してはどうでしょうか。トランザクション(入力データ)に着目して分割するTR分割法や、データの流れに着目して分割するSTS分割法などもありますが、通常は図2のように機能をもとに分割します。
図2：モジュール化
この例では5つに分割しましたが、売上集計とインセンティブ計算を1つにまとめて3つに分割する人もいるでしょう。また、2つのインセンティブ計算をそれぞれ2つに分割して7つのモジュールで構成するケースもあるでしょう。どれも正解です。1つだけ言えるのは、分割しないモノリシックなソフトウェアだけが不正解ということです。この例で言えば、インセンティブ計算と賞与計算の2つのモジュールだけにまとめるのは良いですが、さすがにこれも一緒くたにするのはNG、という感じです。
(3)モジュールのインターフェース
モジュールが独立した形でまとめられるということは、図3のように入力(引数)と出力(戻り値)というインターフェースを持つ構造になります。モジュールは、前回解説したイベント処理や他のモジュールから呼び出されますが、どこから呼ばれるとしても、インターフェースを明確にして作っていれば呼び出し元に依存せず実行されます。
図3：モジュールのインターフェース
(4)モジュール化のメリット
(なぜ、モジュール分割するか)
モジュール化するメリットはたくさんあります。ざっと思いついただけでも次のような効果があるので、ぜひ、何も考えずに身体が勝手にモジュール化するようになってください。
a. 単位が小さく理解しやすい
大きなソースを読み解くシーンを想像してみてください。目指す処理がどこに書いてあるかを探し、書かれているコードの関連性を読み解くだけで大変そうですね。モジュールは1つ1つが小さいため、ソースがとても理解しやすくなります。
b. 変更や拡張などメンテナンスが楽
大きなソースに変更を加えるシーンを想像してみてください。変更個所を見つけるのも一苦労ですし、変更が他の部分にどう影響するかを調べるのも大変です。モジュールは、そこだけ変更すればよく、インターフェースで独立しているため他のモジュールには影響が及びません。
c. 共通化できる(再利用可能)
いろいろなプログラムで同じ処理を記述しているシステムを想像してみてください。その処理に変更を加える場合は、すべてのプログラムに手を入れる必要があります。この処理をモジュールとして共通化して独立させれば、変更が必要になっても1か所を修正するだけで済みます。
d. 中身を隠ぺいできる(カプセル化)
モジュールには「この値を引数として与えると、こういう結果を戻り値として返す」というインターフェースが用意されており、処理内容は隠ぺいできます。この性質を利用すれば、個々の部品(モジュール)単体で独立してテストできますし、処理内容が完成していなくてもインターフェース部分だけを作れば他のモジュールのテストを進められます。
e. 生産性向上
モジュール1つ1つが再利用可能なため、部品を組み合わせてシステムを構築できます。また、上記のようにテスト効率も高まります。さらにソースの可読性が高まるなどのメリットもあり、モジュール化を行うことで生産性が向上します。
- 麻里：先輩、モジュール化とオブジェクト指向ってどう違うんですか?
- 先輩：お、良い質問ですねぇ。
- 麻里：あれ、先輩、今日は池上 彰さんですか? いや、なんかモジュール化の説明を聞くと、オブジェクト指向とどこが違うのかってわかんなくなっちゃって…。
- 先輩：ひと言で言うと、モジュール化はソフトウェア設計の基本的な大原則で、オブジェクト指向はそれを実現する1つの手法ということかな。
- 麻里：大原則と手法の1つ…ですかぁ。
- 先輩：うん、モジュール化は1970年の構造化プログラミングが盛んに議論されていた頃に生まれたソフトウェアの設計原則なんだ。現代まで、この原則は一丁目一番地にあり続けている。
- 麻里：あれ、先輩、今度は政治家ですか? それはそうと1970年って…。
- 先輩：はは、そんな生まれてもいない頃の話はどうでもいいか。まぁ、とにかくソフトウェアの世界に浸透したモジュール化は自動車産業とか他の産業でも同様に広まって、今や全ての産業における大原則になっているんだ。
- 麻里：なんかハードウェアだとモジュール化というよりコンポーネント化って言葉の方がしっくりきますけど、とにかくそういうことなんですね。
- 先輩：まぁ、モジュールの方が柔軟に変更できそうなイメージはあるけど、どっちも部品化という意味合いだからね。
- 麻里：で、オブジェクト指向プログラミングは?
- 先輩：モジュール化の原則にのっとって、より具体的に進化させた手法かな。カプセル化やクラスとインスタンスなどの概念が具体的に定義されて、継承などの考え方も加わっている。
- 麻里：あ、それじゃあ、前回聞いた関数型プログラミングは?
- 先輩：それは、オブジェクト指向プログラミングを進化させようとして登場したプログラミング手法だね。これももちろんモジュール化の大原則にのっとっているよ。
- 麻里：う～ん…。恋愛の大原則が「相手を褒める」ことだとすると、その具体的手段が「「具体的に褒める」「内面を褒める」などのテクニック。その進化系が「長所を3つ見つける」とか「他人と比較しない」とか、長所を見つける方法論ってところかな。
- 先輩：いつも自分の理解しやすいワールドに持っていくねぇ。ところで、そういえば、僕はまだ一回も麻里ちゃんに褒められた覚えがないなぁ…。
ロジック(モジュール)
さて、モジュール化について共有したところで、次はソフトウェアとモジュールの関係をCADを例に見ていきましょう。
(1)ロジック一覧
画面1は、CADツールで作成したロジック一覧画面の例です。「受注削除」「受注更新」「受注検索」「商品名取得」「商品検索」などロジックの設計データが並んでいますね。ここではロジックと呼んでいますが、上記で説明したモジュールとほぼ同じ意味合いのものです。インターフェースを持ち、部品として共有され、機能単位に小さな処理にまとめられています。
画面1：CADのロジック一覧画面
ロジック定義をどのように標準化しているか、具体的に見ていきましょう。画面2は「受注検索」ロジックの定義画面です。上部にタブが並んでいるので、左から順番に解説していきます。
画面2：ロジックの基本情報
(2)基本情報
基本情報タブでは、ロジック名(論理名と物理名)や作成者のほか、プログラムタイプ(通常のプログラムかストアドプログラムか)などを登録します。スコープで「共通」か「個別」かを指定していますが(ここでは共通が選ばれている)、これはそのロジックが複数の呼び出し元から共通利用されることを示しています。
概要には、このロジックが何をするものかを簡単に書いています。エンジニアの中には、このような概要記述を軽視する人もいますが、第三者がパッと見て理解できる内容を書いておくことは意外に重要です。私は最初に設計チームに概要の書き方を指導するようにしています。
履歴欄には変更履歴が記録されます。ロジックは独立したモジュール設計書なので、画面や帳票などの機能設計書全体の変更履歴の他に、単独で変更履歴を持つようにしています。
(3)インターフェース・アクション
モジュールのインターフェースを図3に示しましたが、それを実際に定義しているのが画面3のインターフェース・アクションです。左側のインタフェース欄は図3左部分と同じで、引数(I/O欄がI)と戻り値(I/O欄がO)が定義されています。ここでは、受注一覧画面の検索条件の項目を引数として受け取り、条件に合致した受注データをオブジェクトとしてリターンすることが定義されています。
右側のアクション欄は、図3右部分と同じく、このロジックがどのテーブルのどの項目にアクション(操作)するか(ここではリードRのみ)を定義しています。取得した各項目をオブジェクトとして戻り値にセットしているわけです。
画面3：ロジックのインターフェース・アクション
ソフトウェアを設計するシステムエンジニアとプログラミングするプログラマーが別だった場合、どちらがモジュール分割をするのが良いでしょうか。これは一概に言えず、結果的にきちんと分割できればどちらでも良いでしょう。設計者は必要な仕様だけを記述し、実装(モジュール分割)はプログラマーがいい塩梅に行うのも、現代のソフトウェア開発ではアリかと思います。ただ、私はこの例のようにソフトウェア設計でモジュール分割を行うスタイルに慣れているので、そうしないとちょっと不安なタイプです。
(4)処理内容と補足説明
ロジックの処理内容については、箇条書きで書けるフォーム(処理内容)とExcelキャンバスに自由記述するフォーム(補足説明)を用意しています。簡単な処理であれば、画面4のように処理内容に箇条書きで書く方が楽です。でも、処理内容が複雑で図表なども含めたい場合は補足説明タブに記述します。
画面4：ロジックの処理内容
(5)メッセージ
画面5は、ロジックで発生するエラーメッセージなどを定義するページです。中ほどにメッセージ辞書というボタンがありますね。CADではメッセージの辞書化(メッセージを一元管理して、各機能でそれを共有利用する)を行い、どこでどんなメッセージを使っているかを一元管理する仕組みにしています。
画面5：メッセージ
おわりに
今回はモジュール化を中心に解説しました。ロジック(モジュール)にはIn(引数)とOut(戻り値)のインターフェースがあること、ロジックからデータ(テーブル)に操作(CRUDなどのアクション)を定義することがイメージできたでしょうか。また、処理内容には箇条書きフォーマットを用意しますが、複雑なものは自由記述で記載するしかないこと、ロジックで発生するメッセージはディクショナリ―(辞書)で一元管理しておくことなどがポイントです。
次回は、今回説明したモジュールの関連図と影響調査について解説します。
