ソフトウェア設計の表現と評価

要点と定義

ソフトウェア設計では、要件を実現する構造を定め、ソフトウェア要素やユニットの機能、要素間の処理手順と関係を明確にします。設計の表現方法は、何を伝えるかに応じて選びます。

過去の出題で扱った補足として、UMLのアクティビティ図は活動や処理の流れを表し、分岐や並行処理、合流・同期も表現できます。業務の手順を示す場合に適します。設計手法の知識としては、流れ図や状態遷移図などもシラバスに挙げられています。

過去の出題で扱った補足として、オブジェクト図はある時点のインスタンスと、その間のリンクを表します。クラス図がクラスやクラス間の関係を表すのに対し、オブジェクト図は具体的なインスタンスの関係を表す点で区別できます。

クラス図の関連に付ける多重度は、関連の反対側にあるインスタンス一つに対して、何個まで対応するかを示します。条件を片側ずつ数に置き換え、必須か任意か、複数が許されるかを確かめます。過去の出題では、社員と年の対応や、組織と従業員の所属を多重度で表す考え方が扱われました。

オブジェクト指向設計で用いる抽象クラスは、共通の属性や振る舞いをまとめ、サブクラスに継承させられます。属性やスーパークラス、サブクラスを持てますが、抽象クラス自身のインスタンスは生成できません。

モジュールの独立性を高めるには、モジュール間の依存を抑えます。処理に必要なデータ項目だけを引数で渡すデータ結合は、共有データや相手の制御への依存を小さくできます。

レビューは成果物や活動の状況を評価する手段です。ソフトウェア設計書のレビューでは、設計が要件に合うか、設計上の問題がないかを確認します。デザインレビューの目的の一つは、設計工程で成果物の問題を見つけることです。

適用条件と例

たとえば、申込みを受け付けて内容を確認し、条件に応じて処理を分ける手順を示すなら、過去の出題で扱った補足であるアクティビティ図が適します。一方、ある時点で特定の会員と申込記録がどう結び付いているかを示すなら、オブジェクト図で表せます。クラス図は個別の実例ではなく、クラスとその関係を表すときに使います。

多重度を決めるときは、たとえば「各配送に担当者が必ず一人いる」「担当者が配送を受け持たない場合もある」という条件を、別々の方向から読みます。配送一件あたりの担当者数は必須で一人、担当者一人あたりの配送数は任意で複数になり得ます。端点の位置だけで判断せず、反対側のインスタンスを基準に数えます。

モジュール間で値を受け渡す設計では、受け手が必要とする項目を明示すると、共有領域の定義変更などに影響されにくくなります。共通領域や外部宣言データを複数のモジュールが参照する方式は共有データへの依存を生みます。また、制御パラメータで相手の処理を指定する方式は、相手の動作への依存を生みます。

設計成果物のレビューでは、要件と設計書の対応や、設計内容の整合を確認します。たとえば、仕様変更が設計書の関連項目に反映されているかを確かめます。レビューで問題を見つけたら結果を記録し、成果物へ反映します。レビューの実施だけで、全成果物の出荷可否が自動的に決まるわけではありません。

誤りやすい点

図の名前から用途を取り違えないようにします。アクティビティ図は処理の流れ、オブジェクト図はインスタンスとそのリンク、クラス図はクラスとその関係を表します。過去の出題で扱った補足を使うときも、図が表す対象に沿って選びます。