導入
こんにちは、るっちです。
今回は内部設計（詳細設計）で行う事に関して、備忘録として残そうと思います。
内部設計（詳細設計）
内部設計の位置づけは、「要件定義の内容をシステムでどのように実現するのかを検討する」ことです。
内部設計では、システムの入力と出力、データベースへの格納の間で行うシステムの内部処理を設計します。また、具体的なソフトウェア内部のプログラムや、データの処理方法や管理方法、並列処理方法、トランザクション方法、データベース物理設計なども設計します。
主なタスクは以下のようなものがあります。
各作業と成果物は下記のようになります。
| 作業 | 成果物一覧 |
|---|---|
| 画面プログラム設計 | Controller一覧 Controller設計書 画面共通部品設計書 |
| ビジネスロジックプログラム設計 | ビジネスロジック設計書 |
| データベースプログラム設計 | エンティティクラス図 CRUD設計書（必要に応じて作成） |
| データベース設計 | 物理ER図 テーブル定義書 |
画面プログラム設計
画面設計で作成した画面遷移図、画面モックアップ、画面項目定義書をもとに、画面のプログラミングを行います。
MVCモデルは、GUIを持ったアプリケーションのソフトウェアアーキテクトの一つです。GUIアプリケーションの処理の役割を大きく Model, View, Controller に分けて考えるのが特徴です。
Modelとは、ビジネスロジックとエンティティをあわせたものです。エンティティとはデータベースにデータをオブジェクトで表現したものです。（ビジネスロジックとエンティティをあわせてドメインと呼んだりもします）
Viewとは、GUIの画面のことです。Webでは、JSPやThymeleafやHTML、あるいはWebブラウザがViewにあたります。ViewではModelの情報を表示します。
ControllerはModelとViewを制御します。画面からのイベント（リクエスト）を適切なModelに仲介し、Modelの結果をViewに表示したりします。
Controllerは画面遷移図から抽出します。例えば、検索情報を受け取り、検索した結果を一覧で返すControllerや、検索画面へ戻るためのControllerなどです。
Controller一覧に上がっているそれぞれのControllerで行う処理を設計します。
Controllerが行う処理は主に以下のものです。
- リクエストパラメータのバリデーション
- リクエストパラメータの取得
- ビジネスロジックの呼び出し
- レスポンスへのデータ設計
- 画面遷移
Controller設計書は、UMLのシーケンス図やアクティビティ図で記述します。
また、Controllerは状態を持たない（メンバー属性を作成しない）ように作成します。これは、Controllerクラスのインスタンスは複数のリクエストで共用される可能性があるためです。つまり、Controllerクラスはスレッドセーフに作成する必要があります。
画面設計では、UI設計ポリシーを作成しました。UI設計ポリシーでは、共通ヘッダーや共通フッター、共通メニューなどを定義しました。これらを共通部品として設計します。
HTTPセッションは、HTTPというステートレスなプロトコルにおいて、状態を保持するための仕組みです。HTTPセッションを使わなければ、HTTPリクエストが来るたびにまったく別のリクエストとして処理されてしまいます。これでは、ログインなどの認証や、ECサイトでの買い物かごを実現できません。一般的なのはCookieを使う方法です。
HTTPセッションはWebシステム開発するうえで必須の機能です。HTTPセッションの設計では、HTTPセッションにどのような情報を格納し、その情報がどこで作成されて、どこで破壊されるかというセッション情報のライフサイクルを設計します。
セッション情報を設計するには、クラスタ構成でのセッション管理方法が影響します。セッション共有を行う場合は、セッション情報があまりに大きいと他サーバーへの共有に時間がかかります。セッションに格納する情報は最低限のものにする必要があります。
ビジネスロジックプログラム設計
ビジネスロジックは、ユースケース記述やビジネスルールに書かれた業務に関するシステムの処理です。ビジネスロジックのプログラミング方法にはいくつかパターンがありますが、ここでは TransactionScript と DomainModel について紹介します。
TransactionScriptでは、ビジネスロジックをメソッドにして、Serviceクラスに集めます。例えば、OrderServiceにはorderやlistOrderやcancelOrderなどのメソッドを作成します。TransactionScriptはドメインのエンティティなどの状態を持ちません。オブジェクト指向では、データと処理を1つのクラスで管理してカプセル化するのが普通ですが、TransactionScriptではカプセル化のメリットである仕様変更に対する強さを失う代わりに簡単に設計ができます。手続き型言語のアプローチに似ています。
DomainModelでは、ビジネスロジックにエンティティを持たせます。エンティティはカプセル化とポリモーフィズムを実現できます。概念モデルから抽出されたエンティティに自然な形でビジネスロジックを配置できます。
データベースプログラム設計
データベース設計に関する説明は長くなりそうなので、簡単に概要だけを記載させてください。。。。
DAOパターン
DAOとはData Access Objectの略で、永続化処理を永続化されるオブジェクトから分離し、DAOクラスに隠蔽するためのパターンです。基本的にエンティティに対して1つ作成します。
エンティティクラス図の作成
概念モデルをもとにしてエンティティのクラス図を作成します。
- 概念モデルの日本語のクラス名や属性名を英語にする
- アクセサーメソッドを追加する（getter、setter）
- クラスの関連に方向（矢印）を付ける
トランザクションの制御
データベースのトランザクションとは、データベースへの操作をまとまった単位で確定させる仕組みです。
以下の2点に注意して設計します。
- トランザクションスコープ
- トランザクションアイソレーションレベル
データベースロック
同じデータを他のトランザクションが更新することを制御する仕組みです。ロックの範囲を最小限にすることでパフォーマンスの改善とデッドロックを回避します。
コネクションプール
サーバープログラムは大量のリクエストを処理するために、データベースコネクションを再利用します。データベースコネクションを再利用することで大幅な性能改善が行えます。
マスタのキャッシュ
多くのアプリケーションで性能のボトルネックになるのは、システム外部へのI/O処理が発生する場合です。データベース操作やファイル操作、通信処理などです。I/Oの回数を減らすためにはデータキャッシュが有効です。
データベース設計
物理ER図の作成
データベース論理設計で作成した論理ER図から物理ER図を作成します。
- テーブル名と列名を英語表記にする
- 列の型やサイズを付ける
- パフォーマンス設計を行う
パフォーマンス設計
データベース物理設計で一番重要なのが、データベースパフォーマンス設計です。多くの人は、開発が終わってから負荷テストを行い、パフォーマンスに問題があればチューニングすれば良いと考えているかもしれません。確かにデータベースのパフォーマンスは実際に動かしてみないとわかりません。ただ、設計の段階でもパフォーマンスを向上させるためにできることはあります。
データベースのパフォーマンスで重要な点は以下の4点です。
- I/Oを減らす
- インデックスでデータを見つけやすくする
- 結合を簡単にできるようにする
- 処理はまとめて行う
テーブル定義書の作成
データベース論理設計とデータベース物理設計で作成したER図をもとに、テーブルごとの詳細な仕様を定義します。Excelなどで作成すると良いでしょう。
テーブルについての仕様定義項目は、以下の2点です。
- テーブル名
- スキーマ名
列ごとの仕様定義項目は以下の通りです。
- 論理列名
- 物理列名
- データ型
- 長さ
- 精度
- 必須
- デフォルト
- 主キー
- 外部キー
- インデック
終わり
以上、内部設計に関する備忘録でした。
テスト設計にも触れようか迷いましたが、今回は割愛で許してください。。
他にも備忘録として残しておくと良さような知識を持っていらしたら是非とも共有してほしいです。
次回はアーキテクチャについて残そうと思います。