ソフトウェア設計に関するメモ
2022/05/10, last updated 2022/08/03 - ~3 Minutes
はじめに
もう、30年程前になるが、ソフトウェアの設計法について教えてもらったことがある。 教えてもらった当時は、こんなものは使えない、と思っていたが、視野が狭かった。 今思うと、誰かが提案したソフトウェア開発技法は、全てをカバーできるわけではないが、使える場合も多いように思う。
今でも使えるのではないかと思うので、メモとして残しておこうと思う。
これらの手法は、作図の作法があるが、こだわりすぎると時間もかかって嫌になるので、コンセプトに添っていれば良いのではないかと、私は思う。
設計手法
フローチャート
処理の流れを図示するもの。コードを読めなくても処理内容がわかるので、今でも使われている部分はあるだろう。
DFD (Data Flow Diagram)
データとそれを処理するプロセス、という形で図示するものである。プログラムの分割方法を考えるのに役に立つと思う。
ERD / ER 図 (Entity Relation Diagram)
データベース設計に使う。テーブルとテーブル間の関係を示すのに非常にわかりやすい。
概念設計の段階から使えるのだろうが、私は活用したことがない。
状態遷移図、状態遷移表
処理の最初から最後まで分岐やループで記述できればよいが、何かの処理の完了を待つ必要があり、状態(state)を見て判断する必要があると思う。
そのような場合に、状態遷移図、状態遷移表を活用する。
状態遷移図、状態遷移表は相互に変換できる。
テストまで考えると網羅性のある状態遷移表のほうが好まれるが、検討段階では見やすさから状態遷移図のほうが向いているように思う。
外部設計では状態遷移図で、内部設計では状態遷移表、という感じの使い分けだろうか。
シーケンス図
各コンポーネント間のメッセージのやりとりを図示するのにわかりやすい。
例えば、クライアントとサーバ間でのデータのやりとりや、リクエスト/レスポンスなどをシーケンス図で示すケースが多いと思う。 クライアント/サーバに限らず、システム内のコンポーネント間、機器間の通信などでも使う。 ひとつの図に全ケースを表わすのが難しいので、私の場合は、正常系、異常系に分けて記述することが多かった。
シーケンス図は、私はわかりやすいと思うのだが、見慣れていない人にはわかりづらいと不評だ。 クライアント、サーバーの絵を書いて、その間に流れるメッセージを示す、という、シーケンス図を変形したようなもののほうが好まれる。 例えば、 wikipedia: OAuth プロトコル や AWS lambda のようなものだ。
使い方
典型的には、
- 外部設計書(または、基本設計書)
- 内部設計書(または、詳細設計書)
- 単体テスト仕様書、報告書
- 結合テスト仕様書、報告書
などを作っているが、 私はこれらの手法で検討したことを設計書内に記述するようにしている。
ここでは、外部設計は、外部システム、ユーザーとのインタフェースの観点で記述したものを、 内部設計は、ソフトウェア内部の構造の観点で記述したものとする。
外部設計に利用する例
- UI がある場合、画面間の遷移を状態遷移図で記述。
- 外部システムとの、リクエスト/レスポンスをシーケンス図で記述。
- テータベース定義を ER 図で記述。
内部設計に利用する例
- タスクの分割を DFD で記述。
- テータベース定義を ER 図で記述。
- タスクの状態を状態遷移図で記述。
- タスク間のメッセージ通信をシーケンス図で記述。
テスト仕様書に利用する例
- 状態遷移表からテストケースを抽出