基本情報技術者 試験情報＆徹底解説 -新制度に完全対応-

共通ライブラリのオブジェクト指向設計に関する次の記述を読んで，設問1，2に答えよ。

　システムインテグレータのT社は，自社で開発するソフトウェアの品質の安定化，開発の生産性の向上などを目的として，オブジェクト指向を用いた共通ライブラリの設計に取り組んでいる。
　これまでT社では，システム開発において社員検索機能を数多く開発してきた。この機能は，組織情報から特定の社員を探すために使用される。図1に示すように 左側に階層表示されている組織の一つを選択すると，右側にその組織に属する社員及び下位の 組織の情報が表示されるので，目的とする社員が見つかるまで下位の組織を選択して検索する。図1は，左側で金融システム部を選択し，右側に金融システム部に属する社員及び下位の組織を表示している例である。
　T社では，この組織の階層構造情報(以下，組織階層という)を，デスクトップアプリケーションソフトウェア，Webページなどのユーザインタフェースに出力するシステムを開発してきた。　組織階層の扱いは，どの開発プロジェクトにおいても類似するものが多い。そこで，組織階層を扱う機能をユーザインタフェースから切り離して，様々な開発プロジェクトで再利用できるように，共通ライブラリとして設計することにした。共通ライブラリは，オブジェクト指向で設計し，UMLのクラス図で表現する。ここで，共通ライブラリの設計に当たり，共通ライブラリを利用する側のソフトウェアを一律にクライアントと呼ぶことにする。
　まず，分析のためのクラス図を作成した。

〔分析のためのクラス図の説明〕
　組織階層において，ある組織が親の組織(以下，親組織という)をもつ場合，親組織は必ず一つであり，子の組織(以下，子組織という)をもつ場合，子組織の数に制限はない。また，親組織をもたない組織，子組織をもたない組織，親組織も子組織ももたない組織もある。社員は必ず一つの組織だけに属する。

• 組織階層は木構造で管理する。
• クライアントが組織階層を参照する際，組織と社員を共通に扱えるようにするために，どちらも組織エントリとして管理する。

　図2は，分析のためのクラス図である。　次に，組織エントリを管理するクラスの，設計のためのクラス図を作成した。

〔設計のためのクラス図の説明〕
　組織は自身に属する組織エントリのリスト(以下，組織エントリリストという)を属性として保持する。
　この組織エントリリストを設計するためのクラス図を図3に，組織エントリリストに定義する属性と操作の説明を表1に示す。以下，操作をメソッドという。

• 組織エントリリストは，組織エントリをサイズが可変の配列で管理する。
• クライアントは，組織エントリリストに表1のメソッドでアクセス(組織エントリの追加や削除，取出し，走査など)する。

図2の分析のためのクラス図の中の　に入れる正しい答えを，解答群の中から選べ。

次の記述中の　に入れる適切な答えを，解答群の中から選べ。

　共通ライブラリの社内レビューを実施したところ，組織エントリリストのクラス設計に対して次の指摘が挙がった。

〔指摘の内容〕
　組織エントリリストから組織エントリを取り出すとき，クライアントが要素番号を指定する必要がある。全ての組織エントリを取り出すときや，特定条件を満たす組織エントリだけを取り出したいときなど，クライアント側の実装依存が大きくなる。図4にクライアントの走査の例を示す。　共通ライブラリは，組織エントリリストの内部構造をクライアントに意識させず，組織エントリリストの走査を拡張できるように改善すべきである。

　この指摘を受け，組織エントリリストのクラス設計を次の設計方針に従って見直すことにした。

〔設計方針〕

• 組織エントリリストは，より汎用的にするために，任意のオブジェクトを管理できるようにする。
• リストを走査する処理は，別のクラス(以下，イテレータという)に与える。リストでは，このイテレータを生成してeをイテレータに登録することでイテレータがリストを走査できるようにする。
• 共通ライブラリで提供するイテレータは，先頭から順に全ての要素を 走査するメソッドを提供する。
• アクセス方法の統一を目的として，必要なメソッドをインタフェースとして定義する。クライアントは，必ずこのインタフェースを用いてリストを走査することとする。
• クライアントは，共通ライブラリで提供するメソッドと異なる走査をしたい場合は，fする。

　図5は見直し後の設計のためのクラス図，表2は図5のクラス図の説明である。