ソフトウェア設計の基礎

要点と定義

ソフトウェア設計は、ソフトウェア要件を基に、開発側の視点からソフトウェアの構造と要素を定め、要素をプログラム単位まで分割して、各単位の機能や処理の順序、単位間の関係を明確にする作業です。方式設計では要件を最上位の構造やソフトウェア要素に対応付け、より後の詳細設計ではプログラムの細かな処理を決めます。工程の目的を区別することが、設計段階を問う問題の判断に必要です。

クラス図は、クラスとクラス間の関係を表します。多重度は、関連の反対側にある一つのインスタンスから見て、何個のインスタンスと結び付くかを示します。貸出明細は商品ごとに作られ、各明細に商品が一つ対応します。商品は貸出前なら明細と結び付かず、貸出中なら一つの明細と結び付くため、商品から明細への多重度はゼロ件または一件、明細から商品へは一件です。業務上の生成・返却条件をこの個数に対応させることが、多重度を決める根拠です。

クラスの属性は、そのクラスが表す概念に属する情報です。貸出を返却予定日ごとにまとめる場合、貸出期間は貸出年月日と返却予定年月日の間の日数を表す貸出の情報です。一方、貸出料金や延滞料金は個々の貸出明細に関する情報として区別します。属性を割り当てるときは、情報がどの単位で記録・更新されるかを確かめます。

シーケンス図は、オブジェクト間のメッセージを時間順に表します。メッセージの引数には、その処理に必要な入力を渡します。返却予定日の計算には貸出期間と本日日付が要り、貸出料金の取得には貸出期間を渡します。料金は取得される値であって、その取得要求の入力ではありません。処理の目的と、すでに特定されている対象を確かめて引数を選ぶことが、メッセージの設計を読む根拠になります。

モジュールの独立性を高めるには、モジュール間の結合度を低くします。必要な入出力データ項目だけを引数で渡すデータ結合は、共有データや制御情報を介する方式より依存が小さくなります。相手の内部状態を共有したり、実行順を制御する情報に依存したりすると、変更が他のモジュールに及びやすくなります。情報の渡し方から依存の強さを比べることが正答判断に必要です。

処理方式は、要件と実行場所、通信条件を対応させて選びます。従来型のウェブ方式では、画面を切り替えるたびにサーバ側が画面情報を生成し、端末側がそれを読み込みます。端末に読み込んだウェブアプリが処理を行い、必要なデータも端末に用意する設計なら、通信が途切れている間もそのデータを用いた検索操作を続けられる場合があります。サーバ上の情報更新など、通信が必要な処理まで可能になるとは限りません。要件と画面生成・処理の場所を結び付けることが方式選択の根拠です。

設計では、処理が参照・更新するデータも要件から特定します。例えば店舗検索結果に店舗情報とお気に入り数を表示するなら、両方の情報源が必要です。お気に入り操作で数を増やす処理は、お気に入り数を保持する情報を更新します。画面に出す値、変更する値、値を持つデータの対応を整理することで、処理方式や必要な構成を判断できます。

適用条件と例

商品と貸出明細の多重度を考えます。商品一冊ごとに貸出明細を登録し、返却後はその明細と商品との関連を解消する設計なら、貸出前の商品には関連がなく、貸出中の商品には一件の関連があります。また、一件の明細が複数の商品をまとめて表すことはありません。この条件から、商品側はゼロ件または一件、明細側は一件と判断できます。業務ルールが変わり、一商品に複数の明細を同時に関連付けるなら、商品側の上限も改めて設計します。

貸出日が四月十日、貸出期間が三日なら、返却予定日はその日付と期間から計算します。日付計算に貸出料金は不要です。また、商品情報がすでに特定されており、期間ごとの料金が設定されているなら、料金取得の入力は貸出期間です。日付計算と料金取得は別の処理なので、前者の基準日を後者に渡したり、取得される料金を入力として渡したりしません。