4.2. 設計文書の構成/Design document structure

本演習科目において提唱する設計文書の章構成について説明します。

この示す章構成は、大学などの研究現場でのプログラム開発プロジェクトの特性を考慮した章立てになっています。プログラムを設計する時の思考プロセスに沿った順序に内容が並んでいるので、検討を進めていくガイドとなるでしょう。

次に示す9つの章から構成されています。

4.2.1. プログラムの達成目標

プログラムを開発する具体的な目的や目標を書きます。

これによって、注力すべき事項とそうでない事項の判断ができるようになります。また、文書の読者が理解する上で内容の予想を立てる手がかりとなります。

文章だけでもよいでしょうが、理解の助けとなる図表を併用してもよいでしょう。

実行環境として想定する計算機やネットワークの構成や性能数値を書きます。

プログラムの処理性能を見積もったり、処理方式の選択をする時に判断材料となりそうな情報を含めるようにします。

図表を中心に記載します。

実装する物理現象の離散化表現について、プログラムを書く際に参照したい結果を記載します。式の導出過程は必ずしも必要ありません。

図や数式を中心に記載します。

離散化された計算をどのように並列処理したいのかを記載します。

以下のようなことを検討し、図や文章で記載します。

この後に続くプログラム設計に入る前に、プログラムの入力データと出力データを具体的に決めておくことが有用です。

並列化方針のアイデアがある程度具体的に記述できると、プログラムが必要とする入力データや、得られる出力データが見えてきます。

また、シミュレータのプリプロセス(入力データを作成する過程)やポストプロセス (出力データを可視化したり加工したりする過程)について、この時点で決めておかないと、この後のプログラム設計でそれに対応することができません。

シミュレータの外部仕様で記載すべき事項には、次のようなものがあります。

並列処理をするシミュレータは、複数のプロセスの連携動作によって処理を進めますが、実際にプログラミングするのは、個々のプロセスの処理内容です。

単一のプロセスが進めるべき処理について概要を記載します。

ここでは、離散化方針がすでに決まっていますし、外部仕様も決まっていますから、プログラムがどんなファイルを読まないといけないだとか、どんな通信をどんな順番でしないといけない、といったことはすでに決まっています。

すでに決まっている事項については、ここの処理の流れで登場するようにします。特に、今まで書いてきていることと整合性があるように気をつけます。

一方で、プログラムの中の変数や関数についてはまだ何も決めていないので、それらについてはまだ記載しません。

表現としては PAD などのアルゴリズムの記述向けの表記法を推奨します。

離散化方針と外部仕様が決まっていると、１つのプロセスの中で保持する必要のあるデータにどんなものがあるのかが見えてきます。

それらの変数の数量関係を意識しつつ、クラス図を書き始めます。この段階ではクラスとメンバ変数、クラス間の関連(クラスからクラスを指すポインタ型のメンバ変数) までを記載します。

1プロセスの処理内容に登場するさまざまな計算が必要とする情報が漏れなくモデルに登場するか検討します。逆に、計算で必要としないデータを変数として設けていないかという点も検討します。

データモデルの表現形式としてはUMLのクラス図を推奨します。

データモデルが定義できたら、1プロセスの処理内容をシーケンス図として作図します。

1プロセスの処理内容として書いた処理フローが、実際にクラスの間のメソッド呼び出しとして記述できる検討します。

シーケンス図の１つ１つの矢印は、メソッド呼び出しになりますので、シーケンス図の矢印を引きながら、そのメソッドに名前をつけていきます。

計算処理は、計算対象となる変数を保持しているクラスに実行させるのが原則ですので、計算処理を呼び出したい関数から、計算処理を提供するメンバ関数を提供するオブジェクトにアクセスが可能かどうかが、検証ポイントの１つになります。

シーケンス図の形式としてはUMLのシーケンス図がよいでしょう。

シーケンス図を書く過程で名前をつけていったメソッドをデータモデルとして書いたクラス図に書き加えるとクラスモデルが完成します。

ここまで設計しておけば、コーディングの過程ではあまり仕様について悩まずに進められるでしょう。