応用情報技術者 2024年 秋期 午後 問08
オブジェクト指向設計に関する次の記述を読んで、設問に答えよ。
M社は、企業内の複数の情報システムを接続するデータ連携ハブを製造する会社である。M社のデータ連携ハブは、企業の基幹システムを構成するERP(Enterprise Resource Planning)ソリューションやクラウドサービスとデータ連携するための部品であるコネクタの種類が多いことが人気を呼び、売上を増大させている。
M社には三つの事業所に合計約100名が在籍しており、開発部がソフトウェアの開発を行っている。M社のデータ連携ハブに含まれるコネクタを実現するソフトウェアは、ERPソリューションやクラウドサービスの仕様変更に合わせて頻繁に修正する必要がある。また、同じプログラムコードが複数箇所にコピーされているなどの原因によって保守性が低いという課題があり、コネクタの開発コストが増大している。そこで、M社では、コネクタの開発コストを低減させるために、コネクタを構成するソフトウェアを再設計することになり、開発部のN君が担当することになった。
〔コネクタの利用方法〕
N君は、M社のデータ連携ハブのコネクタの利用方法を整理した。図1は、データ連携ハブを用いてデータ送信元システムからデータ送信先システムへ組織データを送信する例である。

データ連携ハブがFTPSを用いて人事システムからデータフォーマットがCSV形式のデータを取得し、データフォーマットや通信プロトコルを変換して別の三つのシステムに送信している。このときデータ連携ハブのコネクタの役割は、通信プロトコルやデータフォーマットの変換である。
〔オブジェクト指向に関する調査〕
N君は、コネクタを再設計するために、オブジェクト指向について調査した。オブジェクト指向では、ソフトウェアを部品化し、部品の組合せによって目的のソフトウェアを作る。この方法では、データとそのデータに対する処理を一つのオブジェクトにまとめるaという設計指針のもと、外部公開するメソッドを定義してオブジェクト内のデータや処理の変更がオブジェクト外に与える影響を小さくする。また、あるオブジェクトの特性を他のオブジェクトに引き継ぐbが可能であり、開発コストを低減できる。また、同名のメソッド呼出しに対してオブジェクトの種類によって異なる処理を実行するcを実現することが可能である。
〔コネクタのクラス設計〕
N君は、コネクタの利用方法を考慮し、オブジェクト指向を用いてコネクタに関係するクラスを設計した。N君が設計したクラス図(抜粋)を図2に示す。

まず、送受信するデータのデータ項目を定義する連携データクラスとそれを親クラスとする組織データクラスを設計し、各クラスに必要な属性とメソッドを設計した。連携データクラスの論理削除属性は、組織データクラスのメソッドからアクセスe。
フォーマットクラス、CSVクラス、XMLクラスは、送信するデータをCSV形式やXML形式に変換(シリアライズ)したり、受信したCSV形式やXML形式のデータを解析して、連携データクラスのインスタンスを生成(デシリアライズ)したりするクラスである。また、XMLクラスのシリアライズのように、親クラスと同じ名称・引数・戻り値のメソッドを定義することをfという。
プロトコルクラス、FTPSクラス、HTTPSクラスは、データ送受信のためのクラスである。コネクタクラス、組織コネクタクラスは、コネクタを実現するためのクラスであり、送受信するデータのデータ項目に応じて処理を行うものである。
図2で設計されたクラスを用いて、図1に記載のデータ連携ハブから製造システム向けにデータを送信する組織コネクタクラスのインスタンスを作成する場合、gクラス及びhクラスから生成したインスタンスを引数に、組織コネクタクラスのインスタンスを作成する。hクラスの送信メソッドの中ではフォーマットクラスのシリアライズメソッドが呼び出されるが、実際にはgクラスのシリアライズメソッドが呼び出される。
〔コネクタの修正〕
N君は、今後予想されるコネクタの修正時に、図2で設計したクラスに対して少ない修正で対応できるか机上で検証した。
図1に記載の人事システムに格納されている研修受講記録データを新たに他システムへ送信する必要がある場合には、①新しいクラスを二つ作成すればよい。また、CSVファイルやXMLファイルの中の講座名などの文字列の文字コードを変換する共通機能が必要となった場合には、②図2のある一つのクラスに文字コード変換のメソッドを追加すればよい。
その後、N君は、コネクタの再設計に関する必要な作業を完了した。
設問1:
本文中のa~cに入れる適切な字句を答えよ。
模範解答
a:カプセル化
b:継承
c:多相性
解説
解答の論理構成
- 設問は “a〜cに入れる適切な字句” を問うています。
- 【問題文】ではオブジェクト指向の三大要素を説明しています。該当部分を引用すると
・「データとそのデータに対する処理を一つのオブジェクトにまとめるaという設計指針」
・「あるオブジェクトの特性を他のオブジェクトに引き継ぐbが可能」
・「同名のメソッド呼出しに対してオブジェクトの種類によって異なる処理を実行するcを実現」 - これらはオブジェクト指向の基本概念であり、
・「オブジェクトにまとめる」=カプセル化
・「特性を引き継ぐ」=継承
・「同名メソッドで振る舞いが変わる」=多相性(ポリモーフィズム)
に対応します。 - よって解答は
a:カプセル化
b:継承
c:多相性
誤りやすいポイント
- a を「抽象化」と誤記するケースが多いですが、抽象化は“共通点を抜き出す”概念であり “データと処理を隠す” とは異なります。
- c を「オーバーライド/オーバーロード」と答えてしまうミス。どちらも多相性を実現する手段であって概念そのものではありません。
- オブジェクト指向三大要素を暗記していても、日本語訳「多相性」を思い出せず「多態性」などと表記ゆれを起こすことがあります。設問は字句一致を求めるので注意が必要です。
FAQ
Q: 「カプセル化」と「情報隠蔽」は同じ意味ですか?
A: 厳密には「情報隠蔽」を達成するための技術的手段が「カプセル化」という位置づけですが、試験ではほぼ同義語として扱われることが多いです。
A: 厳密には「情報隠蔽」を達成するための技術的手段が「カプセル化」という位置づけですが、試験ではほぼ同義語として扱われることが多いです。
Q: 多相性はどのような場面で役立ちますか?
A: 呼び出し側が同一インターフェースでオブジェクトを扱えるため、コードの差し替えや拡張が容易になり、保守性・再利用性が向上します。
A: 呼び出し側が同一インターフェースでオブジェクトを扱えるため、コードの差し替えや拡張が容易になり、保守性・再利用性が向上します。
Q: 継承ばかり使うと設計が複雑になりませんか?
A: 過度の継承は依存関係を増やし設計を硬直化させます。共通機能は継承より委譲(Composition)で共有するなど、バランスが重要です。
A: 過度の継承は依存関係を増やし設計を硬直化させます。共通機能は継承より委譲(Composition)で共有するなど、バランスが重要です。
関連キーワード: オブジェクト指向、カプセル化、継承、多相性、クラス図
設問2:〔コネクタのクラス設計〕について答えよ。
(1)図2中のdに入れる適切な字句を答えよ。
模範解答
d:データ取得()
解説
解答の論理構成
- インターフェースが提供する公開メソッドの確認
【問題文】の図2で、<> コネクタ には
“+ データ取得()” と “+ データ送信(data : 連携データ)”
の2メソッドが定義されています。 - 実装クラスはインターフェースの契約を満たす必要がある
組織コネクタ クラスは “(組織コネクタ は コネクタ を実現)” と明記されており、 コネクタ インターフェースの全メソッドを実装する義務があります。 - 図2中の d の位置を確認
組織コネクタ クラスには “+ データ送信(data : 組織データ)” と
“+ d” が並んでいます。前者はインターフェースの
“+ データ送信(data : 連携データ)” を具体化したものですから、 後者も残りの “+ データ取得()” を実装する箇所と判断できます。 - 以上より、d に入る正しい字句は
“データ取得()” となります。
誤りやすいポイント
- プロトコル クラスの “取得(form : フォーマット)” と混同しやすい
名前が似ていますが、こちらはパラメータ付きの別メソッドです。 - 組織コネクタ の “データ送信” が引数型を “組織データ” に絞っているため、
“データ取得” も同様に戻り値型を変えると考えてしまうケース
(図2には戻り値記載がないため、シグネチャ変更の根拠がありません)。 - インターフェースを「継承」と誤解し、オーバーライド記号を付けるなど
UML 表記のルールを混同してしまう。
FAQ
Q: “データ取得()” には戻り値型の記載がありませんが問題ありませんか?
A: 図2では戻り値型が省略されています。問題文に型指定がない以上、 インターフェースと同一シグネチャで実装すれば要件を満たします。
A: 図2では戻り値型が省略されています。問題文に型指定がない以上、 インターフェースと同一シグネチャで実装すれば要件を満たします。
Q: “データ送信” の引数型が “連携データ” から “組織データ” に変わった理由は?
A: “組織データ” は “連携データ” のサブクラスなので、 より具体的な型で引数を受け取る協変オーバーライドが可能だからです。
A: “組織データ” は “連携データ” のサブクラスなので、 より具体的な型で引数を受け取る協変オーバーライドが可能だからです。
Q: プロトコル クラスの “取得” とコネクタの “データ取得” は役割が違いますか?
A: はい。前者は通信を行ってデータを受信する低レイヤ機能、 後者はフォーマットやプロトコルを組み合わせて上位レイヤで
データを取得する高レイヤ機能という位置付けです。
A: はい。前者は通信を行ってデータを受信する低レイヤ機能、 後者はフォーマットやプロトコルを組み合わせて上位レイヤで
データを取得する高レイヤ機能という位置付けです。
関連キーワード: インターフェース実装、メソッドオーバーライド、協変、UML可視性、契約遵守
設問2:〔コネクタのクラス設計〕について答えよ。
(2)本文中のe、fに入れる適切な字句を解答群の中から選び、記号で答えよ。
解答群
ア:オーバーライド
イ:オーバーロード
ウ:コンストラクタ
エ:できない
オ:できる
カ:デストラクタ
模範解答
e:オ
f:ア
解説
解答の論理構成
-
連携データクラスの論理削除属性の可視性
- 【問題文】に「連携データクラスの論理削除属性は、組織データクラスのメソッドからアクセスe。」とあり、図2では論理削除属性の先頭に「#」が付いています。
- UML で「#」は “protected” を意味し、同じクラスとその派生クラス(子クラス)からは参照できます。組織データクラスは連携データクラスを継承しているため、アクセスは「できる」と判断します。
- よって e は「オ:できる」。
-
親クラスと同一シグネチャのメソッド定義
- 【問題文】に「XMLクラスのシリアライズのように、親クラスと同じ名称・引数・戻り値のメソッドを定義することをfという。」とあります。
- 同一シグネチャで再定義する行為はオーバーライド(override)です。
- オーバーロード(overload)は同名メソッドでも引数が異なり、今回の記述と合いません。
- よって f は「ア:オーバーライド」。
誤りやすいポイント
- 「#」と「-」の取り違え
は protected、- は private。private なら子クラスからはアクセスできず、「エ:できない」を選びがちです。
- オーバーライドとオーバーロードの混同
“同じ名称・引数・戻り値” というキーワードを見落とすとイを選択してしまいます。 - 『できる/できない』の文脈読み飛ばし
UML を見ずに文だけで判断すると可視性を誤解する可能性があります。
FAQ
Q: protected と private の実務的な違いは何ですか?
A: protected は継承関係にある子クラスからアクセス可能、private は宣言クラスの内部だけでアクセス可能です。ライブラリ設計では拡張点を明確にするため protected を使うことが多いです。
A: protected は継承関係にある子クラスからアクセス可能、private は宣言クラスの内部だけでアクセス可能です。ライブラリ設計では拡張点を明確にするため protected を使うことが多いです。
Q: オーバーライド時に戻り値の型を変えても良いのですか?
A: 言語仕様によりますが、同じ型か共変戻り値(親型→子型の方向)であれば許可される言語もあります。いずれにせよ “互換性を保つ” ことが重要です。
A: 言語仕様によりますが、同じ型か共変戻り値(親型→子型の方向)であれば許可される言語もあります。いずれにせよ “互換性を保つ” ことが重要です。
Q: protected 属性に直接アクセスせず、ゲッター・セッターを用意すべきですか?
A: 外部公開の設計ポリシー次第ですが、カプセル化を堅牢にするために getter/setter を介してアクセスさせる方が保守性は高くなります。
A: 外部公開の設計ポリシー次第ですが、カプセル化を堅牢にするために getter/setter を介してアクセスさせる方が保守性は高くなります。
関連キーワード: カプセル化、継承、アクセス修飾子、ポリモーフィズム、メソッド再定義
設問2:〔コネクタのクラス設計〕について答えよ。
(3)本文中のg、hに入れる適切なクラス名を図2中の字句を用いて答えよ。
模範解答
g:XML
h:HTTPS
解説
解答の論理構成
-
送信先システムが使う通信方式とデータ形式を把握
問題文には「データ連携ハブがFTPSを用いて人事システムからデータフォーマットがCSV形式のデータを取得し、データフォーマットや通信プロトコルを変換して別の三つのシステムに送信している」とあります。さらに、製造システム向けの矢印には「HTTPS, XML」と明示されています。
したがって、製造システムへ送信するコネクタは、 ・通信プロトコル:HTTPS
・データフォーマット:XML
を扱う必要があります。 -
組織コネクタ生成時の引数
問題文は「gクラス及びhクラスから生成したインスタンスを引数に、組織コネクタクラスのインスタンスを作成する」と述べています。図2より組織コネクタのコンストラクタは
<> + 組織コネクタ(form : フォーマット、pro : プロトコル)
です。form にはフォーマット系の具体クラス、pro にはプロトコル系の具体クラスを渡します。 -
ポリモorphism(多態性)のヒント
問題文は「hクラスの送信メソッドの中ではフォーマットクラスのシリアライズメソッドが呼び出されるが、実際にはgクラスのシリアライズメソッドが呼び出される」と説明しています。これは「同名のメソッド呼出しに対してオブジェクトの種類によって異なる処理を実行する」多態性(ポリモorphism)の動作であり、form 引数に具体クラス XML を渡すケースを示唆します。 -
以上より
g:データフォーマットを扱う具体クラス → XML
h:通信プロトコルを扱う具体クラス → HTTPS
誤りやすいポイント
- CSV と勘違いする
データ取得元の人事システムが「CSV」だからといって、送信先のフォーマットも CSV とは限りません。送信先で求められる形式を確認しましょう。 - FTPS を選んでしまう
図中で FTPS は販売システム用です。製造システム用は「HTTPS」です。 - インターフェース名と具体クラス名の混同
コンストラクタのシグニチャは抽象型 フォーマット、プロトコル ですが、実際に渡すのは具体クラス XML、HTTPS のインスタンスです。
FAQ
Q: 「フォーマットクラスのシリアライズが呼び出される」とあるのに実際は XML が呼ばれるのはなぜ?
A: 送信メソッドの引数型が抽象クラス フォーマット だからです。実行時には動的バインディングにより、渡された具体インスタンス XML のシリアライズが呼び出されます。
A: 送信メソッドの引数型が抽象クラス フォーマット だからです。実行時には動的バインディングにより、渡された具体インスタンス XML のシリアライズが呼び出されます。
Q: もし送信先が CSV を要求するシステムなら g と h は何になりますか?
A: その場合、フォーマット系は CSV、プロトコル系は送信先で使用する通信方式(例:FTPS など)になります。
A: その場合、フォーマット系は CSV、プロトコル系は送信先で使用する通信方式(例:FTPS など)になります。
Q: コンストラクタに直接 CSV などを new して渡すべきですか?
A: DI(依存性注入)を意識し、生成はファクトリや設定ファイルで行い、組織コネクタは抽象型で受け取るのが保守性向上につながります。
A: DI(依存性注入)を意識し、生成はファクトリや設定ファイルで行い、組織コネクタは抽象型で受け取るのが保守性向上につながります。
関連キーワード: 継承、多態性、オーバーライド、インスタンス化、抽象クラス
設問3:〔コネクタの修正〕について答えよ。
(1)本文中の下線①について、作成する二つのクラスは、図2中の異なるクラスを親クラスとする必要がある。作成するクラスの親クラスとすべきクラス名を図2中の字句を用いて全て答えよ。
模範解答
連携データ、コネクタ
解説
解答の論理構成
- 下線①は「人事システムに格納されている研修受講記録データを新たに他システムへ送信する必要がある場合には、①新しいクラスを二つ作成すればよい。」という場面です。
- 研修受講記録データは既存の「組織データ」と同じ“データそのもの”の仲間なので、データ項目を定義する親クラスと同じ系統に置く必要があります。図2では「組織データ」は「連携データ」を継承しており、引用すると「組織データ は 連携データ を継承」と記載されています。よって新しいデータクラスも「連携データ」を親クラスとするのが自然です。
- 一方、そのデータを送受信するコネクタも追加しなければなりません。図2では「組織コネクタ は コネクタ を実現」とあるように、各データ用コネクタは共通インタフェース「コネクタ」を実装して作られています。したがって新設するコネクタクラスも「コネクタ」を親(実装元)とする必要があります。
- 問題文は「作成する二つのクラスは、図2中の異なるクラスを親クラスとする必要がある」と明示しており、上記②③のとおり親はそれぞれ異なり、「連携データ」と「コネクタ」となります。
- よって解答は「連携データ、コネクタ」です。
誤りやすいポイント
- データクラスの親を「組織データ」と勘違いしてしまう
「組織データ」は既存データ専用の子クラスであり拡張ポイントは「連携データ」です。 - 新コネクタの親を「組織コネクタ」としてしまう
「組織コネクタ」は特定データ用の実装クラスで共通化されていません。親はインタフェース「コネクタ」です。 - 「フォーマット」「プロトコル」など他の抽象クラスを選んでしまう
下線①はデータ種類追加の話であり、通信方式やファイル形式の追加ではありません。
FAQ
Q: 既存の「連携データ」を直接拡張せずに全く新しい基底クラスを作る選択肢はありますか?
A: ありません。図2で全データの共通属性(例:「# 論理削除 : boolean」)を保持しているのが「連携データ」であり、再利用・共通処理の恩恵を受けるためにも継承先は「連携データ」とするのが設計方針です。
A: ありません。図2で全データの共通属性(例:「# 論理削除 : boolean」)を保持しているのが「連携データ」であり、再利用・共通処理の恩恵を受けるためにも継承先は「連携データ」とするのが設計方針です。
Q: 「コネクタ」はインタフェースですが、“親クラス”と表現して良いのでしょうか?
A: 本問では抽象クラスもインタフェースも包含して「親クラスとすべきクラス名」を尋ねています。Java等ではインタフェースも実装元として“親”と表現する文脈があり、本問もその扱いです。
A: 本問では抽象クラスもインタフェースも包含して「親クラスとすべきクラス名」を尋ねています。Java等ではインタフェースも実装元として“親”と表現する文脈があり、本問もその扱いです。
Q: 新データ送信に際して「フォーマット」や「プロトコル」の派生クラスは追加不要ですか?
A: 研修受講記録データは既存と同じCSV/XMLやFTPS/HTTPSを使う想定のため追加不要です。ファイル形式や通信方式が増える場合にのみそれぞれの抽象クラスを継承して新クラスを作成します。
A: 研修受講記録データは既存と同じCSV/XMLやFTPS/HTTPSを使う想定のため追加不要です。ファイル形式や通信方式が増える場合にのみそれぞれの抽象クラスを継承して新クラスを作成します。
関連キーワード: 継承、インタフェース、抽象化、クラス設計、再利用
設問3:〔コネクタの修正〕について答えよ。
(2)本文中の下線②について、文字コード変換のメソッドを追加すべきクラス名を図2中の字句を用いて答えよ。
模範解答
フォーマット
解説
解答の論理構成
-
追加すべき機能は下線付きの本文に示されています。
― 本文:「CSVファイルやXMLファイルの中の講座名などの文字列の文字コードを変換する共通機能が必要となった場合には、②図2のある一つのクラスに文字コード変換のメソッドを追加すればよい。」
ここで対象は「CSVファイル」や「XMLファイル」と明言されています。 -
図2でファイル形式(CSV, XML)に直接関与するクラスを確認します。
― 図2:「クラス名:フォーマット」「クラス名:CSV」「クラス名:XML」
いずれもデシリアライズ/シリアライズを担当し、データの文字列を扱う層です。 -
「共通機能」であることから、個別クラス「CSV」「XML」ではなく、それらの親クラスが最適です。
― 図2:「CSV は フォーマット を継承」「XML は フォーマット を継承」
親クラスに追加すれば、子クラスで再利用でき保守性も高まります。 -
したがって、②で文字コード変換メソッドを追加すべきクラスは「フォーマット」です。
誤りやすいポイント
- 個別の「CSV」や「XML」を選んでしまう
→ 「共通機能」というキーワードを見落とすと誤答になりやすいです。 - 「プロトコル」クラスと混同する
→ 文字コードは通信ではなくデータフォーマット層で扱う点を整理しましょう。 - クラス図の継承関係を読み違える
→ 親クラスに入れることで DRY 原則を守れることを確認します。
FAQ
Q: なぜ「コネクタ」クラスではないのですか?
A: 「コネクタ」はデータ取得・送信の制御が主目的で、ファイル内容の文字列変換は担当外だからです。
A: 「コネクタ」はデータ取得・送信の制御が主目的で、ファイル内容の文字列変換は担当外だからです。
Q: 文字コード変換は子クラス側でオーバーライドした方が柔軟では?
A: 共通化できる処理は親クラス「フォーマット」に置くことで、重複を防ぎ将来のフォーマット追加時も自動的に利用できます。
A: 共通化できる処理は親クラス「フォーマット」に置くことで、重複を防ぎ将来のフォーマット追加時も自動的に利用できます。
Q: 「フォーマット」クラスに入れると CSV と XML で実装が違う場合は?
A: 親クラスでテンプレートメソッドとして宣言し、子クラス側で必要ならオーバーライドする設計にすれば問題ありません。
A: 親クラスでテンプレートメソッドとして宣言し、子クラス側で必要ならオーバーライドする設計にすれば問題ありません。
関連キーワード: 継承、ポリモーフィズム、カプセル化、共通化、シリアライズ


