業務システムの開発ドキュメント標準化 第5回:詳細設計書(後半)
能設計書のドキュメント体系 |
||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
イベント一覧 |
||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
MVCアーキテクチャに対応 |
||||||||||||||||||||||||||||||||||||||||||||||||||||
|
BL一覧表 |
ビジネスロジック(BL)は、MVCアーキテクチャの処理部分(M)をつかさどるオブジェクトです。図2のように表示部分(V)や入力部分(C)からは直接データにアクセスせず、BLを経由してやり取りを行う構図となります。 図2:MVCアーキテクチャ |
更新・処理仕様書 |
各ビジネスロジックの更新・処理内容は、図4の「更新・処理仕様書」と図5の「補足説明書」に記述します。これまでのドキュメントは"機能"単位で作成するものでしたが、この2つはビジネスロジック単位で作成します。つまり、1機能の中にBLが3つ存在していれば、「更新・処理仕様書」「補足説明書」も3セット作成されることになります。 更新・処理内容の記述は、アプリケーションの内容に応じて異なります。そのため、どこまでテンプレートの形で提供できるかは難しい課題となりますが、DUNGEONではインターフェースとデータ更新処理の2つを「更新・処理仕様書」で表形式とし、そこで表しきれない処理内容を「補足説明書」に記述するようにしています。 図4は「更新・処理仕様書」のテンプレートです。左側の欄には、このBLに対する画面側から見た場合のインターフェース項目が記載されています。どのような引数を渡すか、そしてどんな処理結果をアウトプットとして受け取るかなど、内部処理とは独立した形でインターフェース項目を定義するのです。インターフェースされる各パラメータごとに、I/Oの区別、データ型、サイズ、必須かどうかなどについても定義します。 右側の欄には、このBLから見たデータソースに対する更新処理を記述しています。アクセス対象となるテーブルや列を更新対象データ欄に記述し、列ごとにどのような値をセットするかを更新元データ欄に記述します。 データに対するアクセスには、挿入と更新と削除があります。削除はレコード単位ですが、挿入と更新は列(項目)単位に値を記述する必要があります。挿入と更新で別々にアクセス内容を記述するのは手間なので、本シートではInsertを基準とし、Updateもある場合に更新欄に○を付けることで簡略記述化しています。 BLが受け取った値を元にそのままテーブルを更新する処理は、記述が非常に簡単です。インターフェース欄に書かれた入力項目が、そのまま更新元データ欄に記載され、更新対象データ欄のテーブル/列に対応します。 もう少し複雑な処理も本シートで対応できます。例えば入力項目が「数量」と「単価」、更新対象データが「金額」というような場合は、更新元データ欄に計算式「数量」×「単価」と記載します。丸め処理を定義するような場合は、備考に「少数切捨て」というように記載すれば良いでしょう。 |
補足説明書 |
もっと複雑な処理内容で、本シート上に書き切れないような場合は図5の「補足説明書」に記述します。本シートはBL単位に記述します。標準テンプレートの様式では表し切れなかった処理内容を自由様式で書き加えます。 |
バッチ処理フロー |
詳細設計書の記述対象には、画面や帳票のほかにバッチ処理があります。画面は「画面レイアウト」、帳票は「帳票レイアウト」というイメージ図を基本設計のアウトプットとしていましたが、バッチ処理の場合はその代わりに処理フローを記述することになります。 図6はバッチ処理フローの例です。ここではフローチャート方式での記述となっていますが、どのようなバッチ処理となるかを図示できるのであれば、他の記述様式でもかまいません。とにかく、バッチ処理の概要をイメージで簡単に理解できることが大切なのです。 |
画面遷移図 |
機能設計書に含まれるドキュメントの説明はこれで完了です。画面、帳票、バッチ処理などの機能単位に、このテンプレートをベースに処理を記述していきます。最後にもう1つ、詳細設計フェーズで作成するドキュメント「画面遷移図」のテンプレートを紹介します。 画面遷移図は文字通り画面の遷移(展開)を図で表したものです。図7は画面遷移図の例ですが、これを見ると「プロスペクト一覧」「プロスペクト登録」「見積一覧」「見積入力」などの各画面が、どのような遷移で呼び出されるかを直感的に理解できます。 画面遷移図は対象となる画面を配置し、画面間の呼び出し関係を矢印で表します。ここでは"レベル"という階層の概念を用意しています。このように画面をレベルと対比させて図示することにより、奇妙な画面遷移になることを防止できます。 |
モーダルダイアログとモードレスダイアログ 一般的に、ある画面から別の画面を表示する場合には、新画面を閉じるまでは元画面を操作できない(モーダルダイアログ)と新・元の両方を平行操作可能(モードレスダイアログ)の2種類あります。業務処理などのようにわかりやすい操作を優先する場合は前者、ツールなどのように効率的な操作を行いたい場合は後者が用いられます。 図7の例はモーダル方式だけなのでシンプルな矢印で表現しています。もしも画面によってモードレス方式も併用するようであれば、矢印の種類や色などによりどちらの方式で画面遷移するのかも補足説明することになります。 |
まとめ |
今回は、機能設計書の残りのドキュメントについて説明しました。オブジェクト指向、イベントドリブン型、MVC準拠という現代のアプリケーションに対応した様式になっていることが理解できたと思います。また詳細設計書の最後のドキュメントとして「画面遷移図」も紹介しました。 次回は「テスト仕様書」などテスト工程における標準ドキュメントについて説明する予定です。 |