内部設計の目的と成果物

こちらの記事では、内部設計について解説します。

内部設計

内部設計とは、外部設計を実現するシステム内の処理・構造を決めることです。

https://envader.plus/article/55

処理・構造を決めるといっても、ソースコードを日本語で書くということではなく、処理については概要レベルとプログラムの構造の定義です。

内部設計の目的は主に開発の効率化と仕様と技術のギャップを埋めることです。

まず開発の効率化についてです。開発では共通で利用する機構が多くあるため、もし先にそれらが定義されていなければ、本来共通機構として作るべきだったものを個々の開発者が独自に実装してしまいかねません。そのため、構造レベルでは先んじて設計しておく必要があります。

また、仕様とその実現技術にはギャップがあります。例えば画面の項目とDBのカラムが常に対応したものがあるとは限りません。DBのあるカラムに対して何らかの演算をしたものを画面に項目として出すのであれば、開発者は画面仕様とDBのカラムだけ見てもその対応を察することは難しいでしょう。仮に推察しても、常に誤解の危険がつきまといます。

開発物が比較的小規模な場合にはある程度見通しがききやすいため、このような問題が生じる危険も低かったり仮に起きてもすぐわかるということもあり得るため、内部設計の実行コストを考慮した結果、内部設計しないという判断もあり得るかもしれません。しかし大規模開発の場合は全体を見通すのは難しく、人員の質も担保できないこともあり、内部設計をしなければ破綻する可能性があります。

内部設計の成果物

内部設計の成果物にはいくつか代表例はあります。しかし、会社によって何を成果物とするかは違いが大きい部分でもあります。そのため、自身が成果物を作る立場になったら、その会社の成果物が一体何を目的としたものなのかを都度把握し、その目的を達成できるものを作る必要があるでしょう。

ここでは内部設計の成果物を以下の3種類に分類し、それぞれの代表例を挙げるにとどめます。

• ユーザーの一連の動きの定義

システムを構築する上で、時間軸で全体としての動きを把握する必要があります。この「全体」にはユーザーの動きも含まれます。

そこで、ユーザーの行為とシステムにおける業務的な判断・動きを一連の流れとして表現した図が求められます。システム側の判断・動きは細かく記述しようとすればコードレベルまで細かく記述できてしまいますが、ここでは業務的な意味の抽象度で記述します。

具体例としては、アクティビティ図が挙げられます。この図ではビジネスプロセスとシステムの制御フローが記述されます。

• システム内部のオブジェクトの一連の動きの定義

上記のような業務的な水準でのフローよりも、もう少しプログラム寄りの水準での流れの把握も必要です。

そこで今度は記述対象をシステムのみに絞って処理の流れを記述する図が求められます。やはりここでもどこまでも細かく記述しようとすればコードレベルまで記述できてしまいますが、ここではクラスやテーブルといったひとまとまりのもの＝オブジェクトレベルで図示します。

具体例としては、シーケンス図が挙げられます。この図では、システムのオブジェクトレベルでの制御フローが記述されます。

• システムを構成する、個々のコンポーネントの構成要素の定義

ここまでは各オブジェクトを所与の前提として、その連携を色々な抽象度で図示したものでした。

ただそのためには、どういうオブジェクトが存在するのかをまず定義しておかなければなりません。

この定義はアーキテクチャレベルでの各コンポーネントについて行われる必要があります。コンポーネントが「画面」なのであれば共通部品定義書を作成しなくてはなりませんし、バックエンドシステムであればクラス図を、DBであれば物理設計書を作成する必要があります。