応用情報技術者 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 : 連携データ)」が定義されています。 - 同じ図に「組織コネクタ は コネクタ を実現」とあるため、組織コネクタはコネクタで定義された操作を実装する必要があります。
- 組織コネクタの一覧を見ると「+ データ送信(data : 組織データ)」が既に記載されています(図2には「データ送信(data : 組織データ)」とある)。インターフェース側の対応する操作は「データ送信(data : 連携データ)」ですから、この対応関係は図の意図上明らかです。
- インターフェースが要求するもう一つの操作「データ取得()」は組織コネクタ側にまだ現れていません。したがって組織コネクタ側の空欄に入るべき語句はインターフェースで定義されている操作名である「データ取得()」です。
結論:d = データ取得()
誤りやすいポイント
- 図中の「+」行が属性なのか操作(メソッド)なのかを誤認する。メソッドは括弧「()」に注目すること。
- 「組織コネクタ は コネクタ を実現」を見落とし、インターフェース側の操作を実装クラスに対応づけないで答える。
- インターフェースのメソッドと実装クラスのメソッドで引数型が違う記述(図では「data : 連携データ」と「data : 組織データ」)を見て、即座に図が間違いだと判断する。図の意味は「組織コネクタは組織データを扱う実装を持つ」ということであり、実コードに落とす際は言語仕様に応じてシグネチャの整合性(同一シグネチャで実装するか、オーバーロードになるか等)を確認する必要があります。
- 型の共変・反変の扱いを誤る。一般には引数の型をより具体的な型に変える(引数の共変)は多くの静的型付け言語では許されない点に注意する(言語仕様に依存しますが、戻り値の共変が許される言語はある、という点は押さえておく)。
FAQ
Q: なぜ空欄に型名(例:連携データ)ではなく「データ取得()」というメソッド名が入るのですか?
A: 図2のインターフェースには操作として「データ取得()」が定義されており、組織コネクタはそのインターフェースを実現しているため、組織コネクタ側にも対応する操作(メソッド名)が必要になります。組織コネクタ側ですでに現れているのが「データ送信」であるため、残る操作は「データ取得()」です。
A: 図2のインターフェースには操作として「データ取得()」が定義されており、組織コネクタはそのインターフェースを実現しているため、組織コネクタ側にも対応する操作(メソッド名)が必要になります。組織コネクタ側ですでに現れているのが「データ送信」であるため、残る操作は「データ取得()」です。
Q: 図の「データ送信(data : 連携データ)」と「データ送信(data : 組織データ)」の違いは問題になりませんか?
A: 図は設計意図を示しており、「組織データ は 連携データ を継承」との関係を前提にしています。設計上は組織コネクタが組織データを扱うことを示していますが、実際にコードでインターフェースを実装する場合は言語仕様に従いシグネチャの整合性を守る必要があります(多くの静的言語では引数の型を変更するとオーバーライドにならない点に注意してください)。
A: 図は設計意図を示しており、「組織データ は 連携データ を継承」との関係を前提にしています。設計上は組織コネクタが組織データを扱うことを示していますが、実際にコードでインターフェースを実装する場合は言語仕様に従いシグネチャの整合性を守る必要があります(多くの静的言語では引数の型を変更するとオーバーライドにならない点に注意してください)。
Q: 「データ取得()」の戻り値は図に明記されていませんが、どのように扱えばよいですか?
A: 図中の「データ取得()」はインターフェース操作として名前が示されているだけで、具体的な実装ではプロトコルクラスの「取得(form : フォーマット) : 連携データ」を呼んで連携データインスタンスを得るなどの実装が想定されます。設計から実装に移す際は、戻り値の型や例外仕様を明確にして実装してください。
A: 図中の「データ取得()」はインターフェース操作として名前が示されているだけで、具体的な実装ではプロトコルクラスの「取得(form : フォーマット) : 連携データ」を呼んで連携データインスタンスを得るなどの実装が想定されます。設計から実装に移す際は、戻り値の型や例外仕様を明確にして実装してください。
関連キーワード: カプセル化、継承、ポリモーフィズム、インターフェース、オーバーライド
設問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:〔コネクタのクラス設計〕について答えよ。
問題文を見る模範解答
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:〔コネクタの修正〕について答えよ。
問題文を見る模範解答
連携データ、コネクタ
解説
解答の論理構成
- 下線①は「人事システムに格納されている研修受講記録データを新たに他システムへ送信する必要がある場合には、①新しいクラスを二つ作成すればよい。」という場面です。
- 研修受講記録データは既存の「組織データ」と同じ“データそのもの”の仲間なので、データ項目を定義する親クラスと同じ系統に置く必要があります。図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:〔コネクタの修正〕について答えよ。
問題文を見る模範解答
フォーマット
解説
解答の論理構成
-
追加すべき機能は下線付きの本文に示されています。
― 本文:「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: 親クラスでテンプレートメソッドとして宣言し、子クラス側で必要ならオーバーライドする設計にすれば問題ありません。
関連キーワード: 継承、ポリモーフィズム、カプセル化、共通化、シリアライズ




