応用情報技術者 2012年 秋期 午後 問08
ディジタルオーディオプレーヤのオブジェクト指向設計に関する次の記述を読んで、設問1~3に答えよ。
M社は、ディジタルオーディオプレーヤを開発している。ディジタルオーディオプレーヤを制御するソフトウェアは、UMLを使用して設計している。現行のディジタルオーディオプレーヤのクラス図を図1に示す。
M社では、このディジタルオーディオプレーヤに、音声フォーマットの追加、曲名の表示方法の追加、及び倍速再生の追加を行うことになった。

〔音声フォーマットの追加〕
現在の仕様では、再生可能な音声フォーマットは2種類あり、それぞれ固有アルゴリズム1、2で対応している。固有アルゴリズムは音声フォーマットごとに開発する必要がある。
今回の修正では、新たな音声フォーマットを1種類追加して、固有アルゴリズム3で対応することになった。また、再生アルゴリズムクラスとフォーマット識別クラスを追加して、今後更に音声フォーマットを追加するときには、フォーマット識別クラスの修正と固有アルゴリズムクラスの追加だけで対応できるようにした。再生アルゴリズムクラスは、各固有アルゴリズムクラスの抽象クラスとなる。フォーマット識別クラスは、再生に使用する固有アルゴリズムを決定する。
〔曲名の表示方法の追加〕
現在の仕様では、選曲のために曲名などを表示する選曲画面がある。最初にアーティスト一覧を表示し、アーティストを選択するとアルバム一覧を表示する。アルバムを選択すると曲名一覧を表示する。
今回の修正では、ユーザの多様な検索に対応するために、様々な曲情報(アーティスト、アルバム、ジャンル、リリース年)を組み合わせて曲を検索できるようにした。
図2に修正後の選曲画面の表示例を示す。

図2の画面を実現するために次のように設計した。各画面をフォルダに相当させた。フォルダの中にはフォルダと曲を格納することができる。そのフォルダの中に更にフォルダと曲を格納することができる。フォルダと曲を同一インタフェースで扱えるように、抽象クラスであるコンポーネントクラスを追加した。また、フォルダクラスとコンポーネントクラスを使用して、フォルダの再帰的なデータ構造を実現した。
〔倍速再生の追加〕
通常再生の他に、2倍速再生と3倍速再生を追加して、三つの再生モードに対応することになった。倍速再生の追加に伴い、再生機能の仕様を次のように整理した。
・曲名を選択して選曲ボタンを押すと選択済みとなる。選曲ボタンは、停止しているときだけ有効で、繰り返して複数の曲名を選択することができる。また、選択済みの曲名を再選択すると選択解除となる。
・停止しているときに再生ボタンを押すと再生を開始する。このとき、選択済みの曲がない場合は停止のまま何もしない。再生とは、通常再生、2倍速再生、3倍速再生の総称である。再生を開始するときは、必ず通常再生から開始する。再生しているときに再生ボタンを押しても何もしない。
・再生しているときにモードボタンを押すたびに、通常再生、2倍速再生、3倍速再生の順番に再生モードが切り替わる。3倍速再生の次は通常再生に戻る。
・再生しているときに一時停止ボタンを押すと、再生を中断して一時停止となる。一時停止しているときに再生ボタンを押すと、中断したところから通常再生で再開する。一時停止又は停止しているときに一時停止ボタンを押しても何もしない。
・選択済みの曲全ての再生を終了すると停止となる。
・停止しているとき以外に停止ボタンを押すと停止となる。停止しているときに停止ボタンを押しても何もしない。
〔クラス図とステートマシン図〕
追加機能に対応して修正したクラス図と再生機能のステートマシン図を、それぞれ図3、図4として作成した。レビューで、ステートマシン図の再生ボタンの状態遷移について、①再生機能の仕様と異なる点を指摘された。


設問1:図3について(1)、(2)に答えよ。
(1)a〜cに入れる適切なクラス名を本文又は図1中の字句を用いて答えよ。
模範解答
a:再生
b:フォーマット識別
c:再生アルゴリズム
解説
解答の論理構成
-
まず、cに相当するクラスを確定します。本文には
「“再生アルゴリズムクラスは、各固有アルゴリズムクラスの抽象クラスとなる。”」
とあります。図3では「固有アルゴリズム1」「固有アルゴリズム2」「固有アルゴリズム3」から汎化矢印が集まる箱が c です。したがって c =「再生アルゴリズム」となります。 -
次に、b を求めます。本文には
「“フォーマット識別クラスは、再生に使用する固有アルゴリズムを決定する。”」
と記載されています。図3で b は a から上方向に関連し、再生系と独立に“判定”役を果たしている位置です。この役割はフォーマット識別クラスそのものなので b =「フォーマット識別」と決まります。 -
最後に、a を決定します。図3で a はシステム全体の起点として b(識別)と c(アルゴリズム)を利用し、下側に「選曲」も保持しています。本文で繰り返し登場する中心機能は
「“ディジタルオーディオプレーヤを制御するソフトウェア”」
の“再生”機能であり、旧図でも“再生”クラスが最上位に描かれていました。よって a =「再生」となります。
以上より
a:再生
b:フォーマット識別
c:再生アルゴリズム
a:再生
b:フォーマット識別
c:再生アルゴリズム
誤りやすいポイント
- 「フォーマット識別」と「再生アルゴリズム」の役割を逆に読み取る
→ 識別は“決定”役、アルゴリズムは“実処理”役である点に注意が必要です。 - 図3で矢印の方向だけを見てaを「選曲」と誤判断する
→ 「選曲」はaの子要素であり、最上位ではありません。 - “抽象クラス”という語に惑わされ、cを「固有アルゴリズム」と書いてしまう
→ “固有”は具象クラス、抽象側が「再生アルゴリズム」です。
FAQ
Q: 「フォーマット識別」は具体的には何を行うクラスですか?
A: 再生要求を受けたとき、その音声データがどのフォーマットかを判定し、対応する「固有アルゴリズム1~3」インスタンスを「再生」クラスに知らせる責務を持ちます。
A: 再生要求を受けたとき、その音声データがどのフォーマットかを判定し、対応する「固有アルゴリズム1~3」インスタンスを「再生」クラスに知らせる責務を持ちます。
Q: 新しくフォーマットを追加する際、修正が必要なのはどのクラスですか?
A: 本文にある通り「フォーマット識別クラスの修正」と「固有アルゴリズムクラスの追加」だけで済みます。既存クラスには手を入れない設計になっています。
A: 本文にある通り「フォーマット識別クラスの修正」と「固有アルゴリズムクラスの追加」だけで済みます。既存クラスには手を入れない設計になっています。
Q: 「再生」クラスが直接アルゴリズムを持たず抽象クラス経由にしたメリットは?
A: 開放/閉鎖原則を満たし、アルゴリズム追加時に「再生」クラスを変更せずに済むため保守性が向上します。
A: 開放/閉鎖原則を満たし、アルゴリズム追加時に「再生」クラスを変更せずに済むため保守性が向上します。
関連キーワード: 抽象クラス、汎化、責務分割、開放閉鎖原則
設問1:図3について(1)、(2)に答えよ。
(2)d〜fに入れる適切な図を解答群の中から選び、記号で答えよ。解答は、重複して選んでもよい(dとeは順不同)。

模範解答
d:オ
e:カ
f:カ
解説
解答の論理構成
-
「フォルダと曲を同一インタフェースで扱えるように、抽象クラスであるコンポーネントクラスを追加した。」
─ 「同一インタフェース」は汎化関係を意味します。従って
・フォルダ → コンポーネント
・曲 → コンポーネント
の 2 本は汎化線となります。
解答群で汎化(▷)に該当するのは 「カ ◁―――」 です。
よって e=カ、f=カ となります。 -
「フォルダクラスとコンポーネントクラスを使用して、フォルダの再帰的なデータ構造を実現した。」
─ “フォルダがフォルダや曲を格納する”=含有関係です。
─ 含有は「部分がなくなっても全体は残る」ため、完全な一体化(黒菱形:コンポジション)ではなく「集約(白菱形)」を採用するのが自然です。
─ 図1 の凡例でも「集約」は白菱形と示されています。
解答群で白菱形が右端に付くのは 「オ ―――◇」 です。
よって d=オ となります。 -
以上より
d:オ (集約)
e:カ (汎化)
f:カ (汎化)
が導かれます。
誤りやすいポイント
- 黒菱形(コンポジション)と白菱形(集約)の取り違え。今回の要求は「格納できる」であって「消滅と同時に子も必ず消える」わけではないため白菱形を選びます。
- 汎化の矢印向き。UML では“子クラス→親クラス”に向かって三角形が付くため、矢印先が「コンポーネント」側になることに注意が必要です。
- d と e を同じ種類と誤認するケース。d は再帰構造を示す含有、ef はインタフェース統一のための汎化で役割が異なります。
FAQ
Q: 集約ではなくコンポジションにすると何が問題ですか?
A: コンポジション(黒菱形)は「部分オブジェクトのライフサイクルが全体と一致」する前提です。曲がプレイリストなど他の場所でも参照され得る本問のモデルでは不要に制約が厳しくなります。
A: コンポジション(黒菱形)は「部分オブジェクトのライフサイクルが全体と一致」する前提です。曲がプレイリストなど他の場所でも参照され得る本問のモデルでは不要に制約が厳しくなります。
Q: 汎化線の三角形が“塗りつぶし”になっている理由は?
A: 解答群の図記号で三角形は塗りつぶされていますが、UML の仕様上は空白三角形です。問題文が簡略表記しているだけで意味は同じ、すなわち汎化(一般化)を示します。
A: 解答群の図記号で三角形は塗りつぶされていますが、UML の仕様上は空白三角形です。問題文が簡略表記しているだけで意味は同じ、すなわち汎化(一般化)を示します。
Q: 再帰的な構造をどう実装すれば良いですか?
A: フォルダクラスの属性に List を持たせ、追加・削除メソッドで子コンポーネント(フォルダまたは曲)を操作することで実現できます。
A: フォルダクラスの属性に List
関連キーワード: 集約、コンポジション、汎化、再帰構造、コンポジットパターン
設問2:
本文中の下線①について、指摘内容を30字以内で述べよ。
模範解答
再生を開始するときに、通常再生から開始となっていない。
解説
解答の論理構成
-
仕様の確認
【問題文】の倍速再生仕様に、 「再生しているときに再生ボタンを押しても何もしない。」
「再生を開始するときは、必ず通常再生から開始する。」
という記述がある。
特に後者が“開始時は必ず通常再生”であることを明示している。 -
ステートマシン図の挙動
図4では状態「停止」からイベント「再生ボタン」でコンポジット状態「再生」に入るが、 サブ状態「通常再生」への初期遷移(黒丸→通常再生)が描かれていない。
そのため「停止」から「再生ボタン」を押した時にどのサブ状態へ入るかが不定になる。 -
指摘内容の導出
仕様は“必ず通常再生”なのに、図はそれを保証していない。
よって下線①で指摘された相違点は
「再生を開始するときに、通常再生から開始となっていない。」
となる。
誤りやすいポイント
- コンポジット状態に入っただけで初期サブ状態が決まると思い込み、黒丸の初期状態を省略してしまう。
- 「モードボタン」の循環遷移ばかりに注目し、“開始時は通常再生”という基本仕様を見落とす。
- “再生ボタンを押しても何もしない”という文を、開始時にも適用されると誤読してしまう。
FAQ
Q: コンポジット状態に初期遷移を描かない場合、どう解釈されますか?
A: UML ではサブ状態が不定となり、今回のように仕様を満たさない図と見なされます。
A: UML ではサブ状態が不定となり、今回のように仕様を満たさない図と見なされます。
Q: 「再生」コンポジット状態の右上に“通常再生”を描いただけでは不十分ですか?
A: 不十分です。開始時にそのサブ状態へ入ることを示す黒丸→“通常再生”の遷移が必要です。
A: 不十分です。開始時にそのサブ状態へ入ることを示す黒丸→“通常再生”の遷移が必要です。
Q: 仕様と図が食い違った場合、どちらを優先して修正すべきですか?
A: 仕様(テキスト)が正である前提なので、図を仕様に合わせて修正するのが基本方針です。
A: 仕様(テキスト)が正である前提なので、図を仕様に合わせて修正するのが基本方針です。
関連キーワード: ステートマシン、初期状態、コンポジット状態、抽象クラス
設問3:
図4について凡例に倣い、選曲ボタン、停止ボタン、全曲再生終了のイベントが発生したときの状態遷移をステートマシン図に追加せよ。ここで、設問2の指摘内容は考慮しなくてよい。
模範解答
(図を参照)


解説
解答の論理構成
-
停止状態でのみ効くイベント
原文に「“選曲ボタンは、停止しているときだけ有効”」とあります。したがって
・停止 で 選曲ボタン が押されても状態は変わらず、そのまま 停止 にとどまる自己遷移を描きます。
他の状態ではボタンが無効なので遷移は描きません。 -
停止ボタンによる遷移
仕様には- 「“停止しているとき以外に停止ボタンを押すと停止となる。”」
- 「“停止しているときに停止ボタンを押しても何もしない。”」
と二つの条件が示されています。
これを図に反映すると
・再生 コンポジット状態(内部の「通常再生」「2倍速再生」「3倍速再生」を包含)→ 停止 の遷移に 停止ボタン を付与
・一時停止 → 停止 の遷移にも 停止ボタン を付与
・停止 に対しては自己遷移として 停止ボタン を追加(押しても何もしないため)
-
全曲再生終了による遷移
仕様「“選択済みの曲全ての再生を終了すると停止となる。”」より
・再生 コンポジット状態 → 停止 に 全曲再生終了 を付与
・既に 停止 のときにこのイベントが来ても変化しないので、停止 の自己遷移に 全曲再生終了 を併記 -
ラベルのまとめ方
問題文に「“イベント発生に対して何もしないものはステートマシン図に記載しない。”」とあります。
自己遷移で“何もしない”場合でも、イベントを図に書くことで「無効動作」を明示できます。今回の解答例では 停止ボタン OR 全曲再生終了 の形で同一矢印にまとめ、可読性を高めています。
誤りやすいポイント
- 選曲ボタン を「停止以外でも押せる」と誤解し、不要な矢印を描いてしまう。
- 停止ボタン の自己遷移を省略し、“何もしない”ケースを図示し忘れる。
- 全曲再生終了 をサブステート(「通常再生」など)から直接 停止 に結んでしまい、コンポジット状態からの遷移という UML の表記ルールを破る。
- イベント名をラベルに書かずガード条件のように扱い、採点対象外になる。
FAQ
Q: 停止ボタンの遷移はなぜ 再生 コンポジット状態の枠から出すのですか?
A: 「“停止しているとき以外に停止ボタンを押すと停止となる。”」とあるため、内部のどのサブステートでも同じ挙動になります。コンポジット状態の境界に矢印を付ければ、内部の全サブステートで共通の遷移になることを UML で示せます。
A: 「“停止しているとき以外に停止ボタンを押すと停止となる。”」とあるため、内部のどのサブステートでも同じ挙動になります。コンポジット状態の境界に矢印を付ければ、内部の全サブステートで共通の遷移になることを UML で示せます。
Q: 全曲再生終了 のイベントは 一時停止 にも描くべきですか?
A: 一時停止中は曲の再生が止まっているので「全曲再生終了」は発生しません。従って 一時停止 からの遷移は不要です。
A: 一時停止中は曲の再生が止まっているので「全曲再生終了」は発生しません。従って 一時停止 からの遷移は不要です。
Q: 自己遷移の矢印を省略しても減点されますか?
A: 無効操作が図に表れないと仕様を満たしているかが判別できません。「何もしない場合は図に記載しない」というルールは“イベント自体を描かない”意味ではなく、“不要な状態を増やさない”という趣旨です。自己遷移でイベントを明示するのが安全です。
A: 無効操作が図に表れないと仕様を満たしているかが判別できません。「何もしない場合は図に記載しない」というルールは“イベント自体を描かない”意味ではなく、“不要な状態を増やさない”という趣旨です。自己遷移でイベントを明示するのが安全です。
関連キーワード: ステートマシン、状態遷移、UML, 抽象クラス、再帰構造


