設計文書の構成/Design document structure ======================================== 本演習科目において提唱する設計文書の章構成について説明します。 この示す章構成は、大学などの研究現場でのプログラム開発プロジェクトの特性を 考慮した章立てになっています。プログラムを設計する時の思考プロセスに 沿った順序に内容が並んでいるので、検討を進めていくガイドとなるでしょう。 次に示す9つの章から構成されています。 プログラムの達成目標 -------------------- プログラムを開発する具体的な目的や目標を書きます。 これによって、注力すべき事項とそうでない事項の判断ができるようになります。 また、文書の読者が理解する上で内容の予想を立てる手がかりとなります。 文章だけでもよいでしょうが、理解の助けとなる図表を併用してもよいでしょう。 動作時のシステム構成 -------------------- 実行環境として想定する計算機やネットワークの構成や性能数値を書きます。 プログラムの処理性能を見積もったり、処理方式の選択をする時に判断材料と なりそうな情報を含めるようにします。 図表を中心に記載します。 計算対象の離散化表現 -------------------- 実装する物理現象の離散化表現について、プログラムを書く際に参照したい結果を 記載します。式の導出過程は必ずしも必要ありません。 図や数式を中心に記載します。 並列化方針 ---------- 離散化された計算をどのように並列処理したいのかを記載します。 以下のようなことを検討し、図や文章で記載します。 - データを複数の計算機に分配する場合。どのような単位で分割するのか。 - 離散化の計算の各ステップで、計算機ごとに独立に進められる部分はどれで、 通信が必要となる部分はどこか。 - 通信にどんなパターンがあるか。 - 通信は具体的にどの変数をどの時点で、どこからどこにする必要があるのか。 - 単一の計算機内で進める計算のうち、マルチスレッド化する部分があったら、 複数スレッドから同一の変数への書き込みの衝突をどのように防ぐか。 プログラムの外部仕様 -------------------- この後に続くプログラム設計に入る前に、プログラムの入力データと出力データを 具体的に決めておくことが有用です。 並列化方針のアイデアがある程度具体的に記述できると、プログラムが必要とする 入力データや、得られる出力データが見えてきます。 また、シミュレータのプリプロセス(入力データを作成する過程)やポストプロセス (出力データを可視化したり加工したりする過程)について、この時点で決めて おかないと、この後のプログラム設計でそれに対応することができません。 シミュレータの外部仕様で記載すべき事項には、次のようなものがあります。 - 入力ファイルの種類の一覧 - 各入力ファイルの作成単位(全体でひとつ or 各プロセスに対してひとつずつ) - 各入力ファイルのフォーマット - 出力ファイルの種類の一覧 - 各出力ファイルの作成単位 - 各出力ファイルのフォーマット - シミュレータの起動時のコマンド引数 1プロセスの処理内容 ------------------- 並列処理をするシミュレータは、複数のプロセスの連携動作によって処理を進めますが、 実際にプログラミングするのは、個々のプロセスの処理内容です。 単一のプロセスが進めるべき処理について概要を記載します。 ここでは、離散化方針がすでに決まっていますし、外部仕様も決まっていますから、 プログラムがどんなファイルを読まないといけないだとか、どんな通信をどんな 順番でしないといけない、といったことはすでに決まっています。 すでに決まっている事項については、ここの処理の流れで登場するようにします。 特に、今まで書いてきていることと整合性があるように気をつけます。 一方で、プログラムの中の変数や関数についてはまだ何も決めていないので、 それらについてはまだ記載しません。 表現としては :term:`PAD` などのアルゴリズムの記述向けの表記法を推奨します。 1プロセスのデータモデル ----------------------- 離散化方針と外部仕様が決まっていると、１つのプロセスの中で保持する必要のある データにどんなものがあるのかが見えてきます。 それらの変数の数量関係を意識しつつ、クラス図を書き始めます。この段階では クラスとメンバ変数、クラス間の関連(クラスからクラスを指すポインタ型のメンバ変数) までを記載します。 1プロセスの処理内容に登場するさまざまな計算が必要とする情報が漏れなく モデルに登場するか検討します。逆に、計算で必要としないデータを変数として 設けていないかという点も検討します。 データモデルの表現形式としてはUMLのクラス図を推奨します。 1プロセスの処理シーケンス ------------------------- データモデルが定義できたら、1プロセスの処理内容をシーケンス図として作図します。 1プロセスの処理内容として書いた処理フローが、実際にクラスの間のメソッド呼び出し として記述できる検討します。 シーケンス図の１つ１つの矢印は、メソッド呼び出しになりますので、シーケンス図の 矢印を引きながら、そのメソッドに名前をつけていきます。 計算処理は、計算対象となる変数を保持しているクラスに実行させるのが原則ですので、 計算処理を呼び出したい関数から、計算処理を提供するメンバ関数を提供するオブジェクトに アクセスが可能かどうかが、検証ポイントの１つになります。 シーケンス図の形式としてはUMLのシーケンス図がよいでしょう。 クラスモデル ------------ シーケンス図を書く過程で名前をつけていったメソッドをデータモデルとして書いた クラス図に書き加えるとクラスモデルが完成します。 ここまで設計しておけば、コーディングの過程ではあまり仕様について悩まずに 進められるでしょう。