はじめに
システム開発において詳細設計という工程があります。
プログラマーはこの詳細設計を確認しながら開発を行うことになります。そのため詳細設計ではシステムの構造や仕様、動作などを細かく定義することが必要になります。
詳細設計を行うことでシステム開発の方向性が明確になり、コーディングやテストをスムーズに行うことができます。
詳細設計の成果物としてはクラス図やシーケンス図、画面設計書やデータベース設計書などがあり、システムの動きや機能を具体的に表現するものです。 今回は詳細設計を作成する機会があったので、詳細設計の書き方についてまとめたいと思います。
詳細設計の目的やメリット
詳細設計の目的は、システム開発の品質や効率を向上させることです。詳細設計では、システムの仕様や動作を細かく定義することで、以下のようなメリットがあります。
- 開発工程でのバグや遅延を減らすことができる
- テスト工程での不具合や修正を減らすことができる
- システムの保守や改修が容易になる
- システムの可読性や再利用性が高まる
基本的な流れ
開発の工程は一般的なウォーターフォール型開発であれば、要件定義、基本設計、詳細設計、開発、テストの順で行われます。
詳細設計は基本設計を元に作成されます。基本設計には簡単に言ってしまえば「何を実現するのか」を決める工程で、詳細設計では「実現する方法」を具体的に決める工程になります。
「実現する方法」を決めるためにはシステムの構造や仕様、動作などを細かく定義します。詳細設計の本的な流れは以下のようになります。
- 基本設計を確認する
- 基本設計書は、「何を実現するのか」を決めるためにシステム開発の方向性や目的を示す重要なドキュメントです。詳細設計では、基本設計書に記載された内容を確認し、不明点や矛盾点がないかをチェックします。また、基本設計書に沿って詳細設計を行うことで、システム開発の一貫性や品質を保つことができます。
- 詳細設計書の作成
- 詳細設計書は、システムの構造や仕様、動作などを具体的に示すドキュメントです。
- 詳細設計書のレビュー
- 作成したドキュメントに対して誤りや不備がないかを確認します。
基本設計書と矛盾していないか
システム要件を満たしているか
プログラミングやテストが可能か
説明が分かりやすく正確か
- 作成したドキュメントに対して誤りや不備がないかを確認します。
詳細設計で作成する成果物は以下になります。
- クラス図：システム内のクラス（オブジェクト）やその関係性を表す図
- シーケンス図：システム内のクラス（オブジェクト）間のメッセージ（処理）の流れを表す図
- 画面設計書：システムの画面やボタン、入力項目などのレイアウトや動作を表す書類
- データベース設計書：システムで使用するデータベースやテーブル、カラムなどの構造や制約を表す書類
クラス図
クラス図はシステムの静的な構造・関係性を視覚的に表現するための図です。
クラス図の書き方 クラスは「クラス名」、「属性」、「操作」を1つの塊で表現し、クラスを繋ぐことでシステム間の繋がりを視覚的に見やすくします。
クラス名 処理ごとにまとめられたクラス名です。
属性 クラスのインスタンスが持っているデータの定義のことです。上の表のユーザー・顧客クラスでは「ユーザー名」、「住所」、「email」、「カード情報」等がそれに当てはまります。
操作 クラス内で実際に行われる操作になります。ユーザー・顧客クラスではログインや情報アップデートの操作が行われます。
矢印
- 「関連」とは文字通り、クラス間の関係性を記述しています。
- 「集約」はクラス同士の関係が「全体と部分」であるときに使用されます。
- 「コンポジット」は集約の一種で、「全体」クラスが「個別」クラスの生成や削除の権利があるときに使用されます。
- 「依存」は「クラス間の弱い関係性がある」場合に使われます。
- 「凡化」はあるクラスAの型を継承してより具体化したクラスBを作成した場合、この2クラスの関係性は具体的なクラスBと抽象的なクラスAという意味で「凡化」関係と言えます。
- 「実現」は共通操作を定義したクラスと個別動作を定義したクラス間の関係を言います。
- 「誘導可能性」は、クラス同士のやりとりの方向性を表現します。片方からのアクセスのみ関係です。
シーケンス図
シーケンス図とは「プログラムの処理の流れや概要」を設計する際に使われます。プログラムの処理の流れや概要について、具体的には「クラスやオブジェクト間のやり取り」を「時間軸に沿って」、図で表現します。
- ブラウザからの商品検索の操作
- サーバーの商品情報取得するメソッドが動く
- データベースから検索結果を取得する
- 外部システムから関連商品所得する
- 検索結果をブラウザに表示する
画面設計書
画面設計書はユーザーインターフェースのイメージやデザインや挙動を定義します。 画面設計書はワイヤーフレームやモックアップとして作成されることもあります。
データベース設計書
データベースは大量のデータを保管・管理するだけでなく、抽出・編集・共有しやすくするためのものです。
代表的なデータベースは「Oracle Database」や「MySQL」等があります。
データベースを設計する上でのポイントは下記になります。
- 要件・仕様を理解し要件を満たすテーブルとカラムが揃えられるか
- 要件にない（見えにくい）システムの仕様を想像できるか
- 必要な正規化がなされているか
- 将来性を考えられるか
まず、要件や仕様を実現するために必要なテーブルやカラムを洗い出します。
また、要件や仕様からでは読み取りにくいシステム的な仕様を把握する必要があります。登録されるデータの特性を考察し、カラムの型やルールを決めます。そして、テーブル間でのリレーションを考える必要があります。 例えば商品としてリンゴがある場合は「商品テーブル」が必要になります。「商品テーブル」のカラムは最低限「商品ID」、「商品名」、「価格」、「登録日」、「更新日」、「削除日」になります。「価格」には数字が入るべきであるのでルールとして数字のみを許可する必要があります。また、「リンゴ」という商品に「果物」というカテゴリーを付属させる場合は「カテゴリーテーブル」を作成し、「カテゴリー名」カラムを持たせます。「商品テーブル」に「カテゴリーID」カラムを追加してこれを外部キーとして「カテゴリーテーブル」とリレーションすることで商品に対してカテゴリーを付属させることができます。
いくつかのテーブルを設計を行う上でカラムの重複はデータの不整合を招くことになるので「カテゴリーテーブル」があるのに「商品テーブル」に「カテゴリー名」のカラムがあるとカラムが重複しているので必要な正規化ができていない状態です。
最後にデータは流動的なのでいつ誰がどのような操作をしたかがわかるように「登録日」や「登録者」等のカラムを用いることによってメンテナンスの効率を高めることができます。