IPA ソフトウェア設計・保守・再利用 — 頻出論点と過去問

頻出論点

1. この分野は何か

1つのプログラムをどんな部品に分け、部品どうしをどうつなぐかで、直しやすさや使い回しやすさが大きく変わります。部品の結びつきの強さ、クラスどうしの関係、繰り返し使える設計の型、稼働後の手直しの種類は、名前と中身の組合せを取り違えやすいところです。

2. 実際の出題のされ方

ソースコードから仕様書を起こす手法、外から見た動きを保ったまま中を整理する活動、公開されたサービスを組み合わせて新しいコンテンツを作る手法については、名前と定義の組合せを選ぶ問題があります。これらはいずれもITパスポートで出ており、ソフトウェア保守に含まれる作業の範囲を判断する問題もあります。

モジュール結合度とオブジェクト指向におけるクラスどうしの関係、保守の分類は、応用情報技術者の午前と高度試験の午前Iの両方にまたがる論点です。結合度では、受け渡し方の説明から結合の名前を当てる問題や、いくつかの受け渡し方のうち結合度が最も低いものを選ぶ問題が繰り返し出題されています。クラスについては、サブクラスとスーパークラスの操作の関係や集約の正誤を判断する問題と、図形描画ツールのクラス図に「継承の分割」を行った後の図を選ぶ問題があります。保守では、問題が起きていないのに仕様書を作り直す作業がどの分類に当たるかが問われています。

高度試験の午前IIでは、設計原則やパターン、システム全体の組み立て方まで踏み込みます。設計原則の説明の見分け、クラス図に示したパターンを当てはめたときの効果、Observerパターンで実現できること、共通の処理を呼び出す記述を外にまとめる技法の名前が出ています。アーキテクチャパターンでは、特徴の説明から名前を選ぶ問題と、名前から説明を選ぶ問題の両方があります。マイクロサービスについては利点と、障害が広がるのを抑える仕組みが問われ、再利用の手法ではマッシュアップの例や、特定の業務分野の知識や部品を整えて使い回す活動の名前を選ぶ問題もあります。

3. 学習のポイント

モジュール結合度は、モジュール同士の結びつきの強さを表す指標であり、結合度が低い（弱い）ほど独立性が高く、保守や再利用がしやすくなります。弱い順（独立性が高い順）に並べて、それぞれのデータの受け渡し方を区別できるようにします。

引数で渡す方が大域的データを共有するよりも結合度が低く、同じ引数渡しや大域共有の中では、データ構造全体よりも必要な単一項目だけを扱う方が結合度は低くなります。

オブジェクト指向の基本概念と設計原則は、クラス間の関係と役割分担に着目して整理します。

• 汎化と継承: 似たクラスから共通する部分を取り出して上位のクラスにまとめるのが汎化で、下位のクラスはその属性や操作を引き継ぎ、必要なら中身を自分用に書き換えます（オーバーライド）。抽象クラスは、引き継がせるための枠として定義し、それ自身からはインスタンスを作らないクラスです。
• 継承の分割: 性質の違う2つの軸（たとえば通知の手段と通知の内容）を1本の継承の木で表すと、組合せの数だけサブクラスが増えます。継承の分割は、この増え方を止め、どちらの軸を増やすときもクラスを1つ足すだけで済むようにするリファクタリングです。
• 設計原則: 開放・閉鎖原則は、機能を足すときに出来上がった部分のコードを書き換えずに済むよう、拡張の口を開けておく考え方です。依存性逆転の原則は、上位の部品も下位の部品も、具体的な作りではなく両者の間に置いた抽象（インタフェース）に依存させる考え方です。また、権限の確認のように複数のプログラムに散らばる共通処理を分離し、呼び出し方の宣言を別に書いて組み込む技法としてアスペクト指向プログラミングがあります。

再利用可能な設計の定石であるソフトウェアパターンは、対象とする粒度によってデザインパターンとアーキテクチャパターンに分かれます。

• デザインパターン: オブジェクト指向で繰り返し現れる設計上の問題と、その解き方の型に名前を付けたもので、GoFのパターンは生成・構造・振る舞いの3つに分かれます。システム全体の骨組みを決めるアーキテクチャパターンとは粒度が違います。たとえばStrategyパターンは処理の手順を差し替えのきく別のクラスに切り出す型で、Observerパターンは、あるオブジェクトの変化を、それを見張る側のオブジェクトへまとめて知らせる型です。
• アーキテクチャパターン: ソフトウェア全体の骨組みの型です。MVCは、データと処理（Model）、画面の表示（View）、入力の受け付け（Controller）を分け、画面を作り替えても中の処理に手を入れずに済むようにします。Brokerは、分散したサービスの間に仲介役を置き、呼び出す側が相手の場所や作りを知らなくても済むようにします。
• マイクロサービスアーキテクチャ: アプリケーションを、それぞれ単独で動かせる小さなサービスに分けて組み立てる方式です。サービスごとに作り替えや配備ができる代わりに、サービス間の呼出しはネットワーク越しになります。呼出し先の不調が全体に広がらないよう、失敗が続いた相手への呼出しをしばらく止める仕組み（サーキットブレーカー）を組み込みます。

保守と既存資産の活用に関する用語は、稼働後の作業かどうか、外から見た動きを変えるかどうか、何を調べ何を整えるかで整理します。

• ソフトウェア保守（JIS X 0161）: 本番稼働（引き渡し）後に行う変更作業です。納入前の開発期間中に行うバグ修正は保守に含まれません。保守は目的に応じて次の4つに分類されます。
  • 是正保守: 引き渡し後に見つかった不具合（バグ）を訂正する保守です。
  • 適応保守: 法改正やOSの更新など、変化した外部環境でも使い続けられるようにする保守です。
  • 完全化保守: 利用者のための改良や、性能・保守性を高めるための手直しとして行う保守です。
  • 予防保守: 潜在的な不良を見つけ、障害として顕在化する前に修正する保守です。
• 既存コードの解析・改善と再利用技法:
  • リファクタリング: 外部から見た機能仕様や振る舞いを変えずに、プログラムの内部構造を改善して保守性を高める手法です。
  • リバースエンジニアリング: 出来上がったプログラムや製品を調べ、そこから仕様や設計を書き起こすことです。
  • ドメインエンジニアリング: 対象とする業務分野を絞り、その分野で繰り返し使う知識や部品、道具を前もって整えておく活動です。
  • マッシュアップ: 他者が公開しているWebの機能やデータを取り込み、組み合わせて新しいサービスやページを作ることです。

4. 間違えやすいところ

• 結合度の名前と受け渡し方の取り違え: 結合度の記述の正誤を問う問題では、JUMP命令で他のモジュールへ直接飛び込む関係を外部結合とする誤答肢がありました。相手の中へ直接入り込むのは、結合度が最も高い内容結合です。引数で渡すのか、大域的なデータを共有するのか、相手の内部に直接触れるのかを先に分け、次に単一のデータ項目かデータ構造かで絞り込みます。
• マイクロサービスの利点と引き換えの取り違え: 利点を選ぶ問題では、各サービスのデータの整合性を確保しやすいとする誤答肢がありました。データがサービスごとに分かれるので、整合性をそろえるのはむしろ難しくなります。
• 継承と集約の取り違え: クラス間の関係の正誤を問う問題では、集約の関係にあるオブジェクトどうしが属性と操作を共有するとする誤答肢がありました。集約は全体と部分のつながりを表すだけで、属性や操作を分け合う関係ではありません。
• 保守の分類の判断: 仕様書と現状のコードの不整合を解消するために仕様書を作り直す作業の分類を問う問題では、これを是正保守とする誤答肢がありました。是正保守は引き渡し後に見つかった不具合を直す作業であり、問題が起きていない状態で行う作業には当たりません。
• リバースエンジニアリングとリファクタリングの取り違え: リバースエンジニアリングに当たるものを選ぶ問題では、ソースプログラムを読みやすく書き換える作業が誤答肢にありました。外から見た動きを保ったままコードを書き換えるのはリファクタリングであり、仕様を書き起こす作業ではありません。