参考情報
本連載は、設計書ジェネレータ「SI Object Browser Designer（以下、OBDZ）」を使ってソフトウェアの設計書（仕様書、基本設計書、詳細設計書）を作る講座です。今回はOBDZのドキュメント体系についてご説明します。
OBDZで作成できる設計書の種類
第16回では理想の設計として「自社の案件パターンごとにテンプレート化する」という提唱をし、OBDZはその発想に基づいたツールであること、ただし、OBDZも大枠ドキュメント体系は決められているため、導入の際はOBDZのドキュメント体系を理解しなければならないという話をしました。今回は、OBDZのドキュメント体系をご説明したいと思います。
前提条件
OBDZの対象となるシステムはクライアントサーバーやWebなどの「業務系システム」となります。例えば、ゲームソフトや組み込み系ソフトウェアの場合は、ご利用が難しいものとなります。また、業務系システムでは基本設計（外部設計）、詳細設計（内部設計）に分けて設計されることが通常かと思いますが、OBDZもこのような段階的設計に従っており、基本設計（外部設計）で骨組みを決め、詳細設計（内部設計）で情報を追加して設計書を作成するかたちとしています。それぞれに分けてドキュメント体系をご説明します。
|
OBDZとDUNGEION（ダンジョン）の関係 |
 OBDZのドキュメント作成方法についてOBDZでも最終的なアウトプットはExcel形式の設計書となりますが、OBDZではあらかじめ専用の入力画面で設計情報を入力し、Excel形式でアウトプットするという２段階方式で作成します。あらかじめ専用画面で設計することで、効率化、品質向上および標準化ができます。OBDZの入力画面のイメージについてはこちらをご覧ください。 |
基本設計書（外部設計書）の種類
基本設計（外部設計）で作成するドキュメントは以下の通りです。
表１．基本設計（外部設計）のドキュメント体系
上記表の「範囲」には、システム単位で作るものであれば「全体」、画面や帳票毎につくる場合は「個別」と記載しています。基本設計で作る成果物としてはER図、テーブル定義書などのテーブル関係ドキュメント、機能一覧表、基本設計書（外部設計書）となります。また、基本設計書（外部設計書）の構成は「概要」「画面/帳票レイアウト」となります。
ER図
設計の世界においてはER図の作成は必須ではありませんが、テーブル数が100を超えるような規模のシステム開発においては、ビジュアルで整理することで項目漏れや不正後等などの設計ミスを防止でます。DUNGEONでもER図の作成を推奨していますが、ER図は別製品であります「SI Object Browser ER（以下､OBER）」で作成するかたちになります。OBDZは2013年にリリースした製品ですが、OBERは2002年にVer.1をリリースし、機能も成熟しています。そのような理由もあり、DB設計はOBER、プログラム/レイアウト等の設計はOBDZがカバーする構成となっています。運用としては、OBERで綺麗なデータベース設計を行い、作成したER図をOBDZのインポート機能で取込むかたちとなります。
図１.ER図
テーブル定義書
ER図以外のテーブル関連ドキュメントとしては、「テーブル定義書」があります。「テーブル定義書」はテーブル名や列ごとのデータ型、長さなどを一覧にしたものです。
図２.テーブル定義書
|
OBERなしではテーブル設計できない？ |
機能一覧
画面や帳票・バッチ名が並んだ一覧表です。明細項目は、標準では「コード」「名称」「種別」「分類」となりますが、フォーマットのカスタマイズ機能で「概要」などの情報を入れることも可能です。
図３.機能一覧
概要
概要は既定では基本設計書の表紙内に表示されます。（表紙とは別シートにすることも可能です。）なお、表紙には「更新履歴」や「分類」も表示されます。
図４.概要（赤枠の部分）
画面/帳票レイアウト定義書
基本設計書（外部設計書）のメインとなる設計情報です。画面や帳票のレイアウトを定義したドキュメントです。OBDZではレイアウトは専用のGUI画面で効率よく作成できるようになっています。個々のレイアウト項目（コントロール）の定義は詳細設計で行います。
図５.画面/帳票レイアウト定義書
詳細設計書（内部設計書）の種類
詳細設計で作成するドキュメントは以下の通りとなっております。
表２．詳細設計（内部設計）のドキュメント体系
詳細設計書（内部設計書）は、基本設計書にある内容に加え、「イベント定義書」「ロジック定義書」などのプログラム情報を付加したものになります。また、補助ドキュメントとしてCRUD図があります。
CRUD図
CRUD図とは、作成（C）、読取（R）、更新（R）、削除（D）の頭文字をとったもので、テーブルのアクセス関連情報を記した表になります。OBDZのCRUD図は「画面（帳票・バッチ）ごと、ロジックごと、テーブルごと」にシステム単位で一括出力される点が特徴です。
図６.CRUD図
コントロール定義書
画面/帳票レイアウト設計で配置したテキストボックスやボタンなどの個々のコントロール項目に、「I/O」や「桁数」などの詳細情報を加えたものを表形式で表した設計書です。OBDZではレイアウト設計画面にあるプロパティを定義することで、コントロール定義情報も自動で作成される形式となります。
図７.コントロール定義書
イベント定義書
「ボタンクリック時」「テキスト変更時」などのイベントと、それに対応した処理を記載する設計書となります。処理を記載する欄としては「内容」列、「ロジック」列があります。「●●画面に遷移する」などの簡単な処理であれば「内容」列のみに記載するかたちで構いませんが、データベース更新するなど、複雑な処理の場合は「ロジック」列に後述のロジック定義書で定義したロジック名を記載します。
図８.イベント定義書
ロジック定義書
プログラムの設計書になります。（ソースコード上ではメソッド、関数単位に置き換えられるものとなります。）明細欄は大きく「パラメータ」「アクション」に分かれています。「パラメータ」欄は引数情報、「アクション」欄には、影響するテーブルや呼び出す画面、サブロジック等を記載します。その他、「エラー定義」ではエラーチェックなどの内容、「処理内容」欄では箇条書きで処理内容が記載できます。OBDZでは「素早く設計書を作成する」ことをコンセプトとしていますので、ソースコードジェネレータにあるような処理分岐も含めた細かな処理内容（アルゴリズム）や変数定義などの記載欄はありません。前提として「設計者はインタフェースのみ定義し、細かな実装方法はプログラマの裁量にまかせる」ものとなっています。ただし、どうしても入れたいという場合は、後述する「補足機能」を使って追記することも可能です。
図９.ロジック定義書
メッセージ定義書
エラーや警告等のメッセージを一覧にしたドキュメントです。OBDZの画面では案件ごとにメッセージマスタを持ち、プルダウンで割り当てて作成しますので、品質の高いメッセージ定義を行うことができます。
図１０.メッセージ定義書
モジュール関連図
モジュール関連図は「I/O関連図」の拡張版のような図で、画面項目やイベント、ロジック等を図示したものです。OBDZではコントロール、イベント、ロジックの情報をもとにモジュール関連図が自動生成される仕組みとなっています。
図１1.モジュール関連図
[RELATED_POSTS]
自社のドキュメントを補う「補足説明」機能
また、OBDZには「補足説明定義書」があります。これは、これまでの設計書で書けない細かな補足事項を書くためのドキュメントとなります。OBDZの補足説明入力画面上はExcelフォームとなっていますので、表や図、フローチャートなどを挟むことも可能です。また、補足説明入力画面で入力した情報は、最終的なアウトプットの設計書（Excel）に追記されて生成されます。もし自社にしかない設計ドキュメントがある場合も、補足説明定義書として追加することが可能となっています。
画面.補足説明入力画面
以上で、OBDZのドキュメント体系をご説明いたしました。自社の設計標準と比べて、ドキュメントが過剰な分には減らすことが可能です。また、自社のドキュメントにしかない設計書がある場合も、ある程度は補足説明定義書で補っていただくことが可能です。しかし、OBDZは従来のExcel等の課題を解決するツールですので、あまりExcelベースの補足機能を多用すると導入のメリットが薄れてしまいます。費用対効果を出すためには、自社のドキュメント体系と概ねマッチしている必要があるでしょう。ぜひ導入の際はご参考にいただければと思います。
