ObjectSquare [2001 年 7 月号]

[オブジェクト指向と情報処理試験 -2001年 春-]


ココが変だよ? 情報処理試験


今年の春に行われました情報処理試験、皆さん、出来栄えはいかがだったでしょうか。

今回、答え合わせも兼ね(?)、オブジェクト指向に関する問題をピックアップして、あれこれツッコミをいれてみました。ケンケンガクガクの議論をお楽しみください。

なおコンテンツはオージス社内のWikiによって作られました。よって中にはスレッドが完結しきっていないものもありますが、続きは広場のMLでどうぞ。



資格別出題数は、

という結果でした。

午後2001年 ソフトウェア開発技術者午後問題はこちらから




(基本:午前・問46) (ソフト:午前・問48)

状態遷移図の説明として、適切なものはどれか。

  • ア 階層構造の形でプログラムの全体構造を記述する。
  • イ 時間の経過や状況の変化に基づいて、そのときの動作を記述する。
  • ウ システムの機能を概要から詳細へと段階的に記述する。
  • エ 処理間のデータの流れをデータフロー、処理、 データストア及び外部の四つの記号で記述する。

(解答) イ

(コメント)

nope どれも納得いかないですけど、あえてひとつ選べばイですね。
ある対象(システム全体でも、プログラム中のオブジェクトでも、外部のファイルでも、隣の遠藤さんでも何でも良い)の取り得る状態と、状態の(イベントや、時間経過に伴う)移り変わりをあらわすものが状態遷移図では?
少なくとも、(ある状態における)「動作を記述する」のが状態遷移図の本位ではないと思います。UMLの状態遷移図でも、状態の中のactivityを記述することはできますけどね。
PaCman まあ問題作成者の意図として、「状態」という語句を選択肢の記述の中に含めたくなかったのでしょうね。問題が簡単になると思ったのでしょう。
でも「状態」という語句を使わずに「状態遷移図」の説明をするというのは無理があるような…。しっくりこない選択肢しか書けない問題を選んだこと自体が問題?
好意の人 "動作"を各状態での動作、ではなく、好意的に"状態遷移"そのもののこと、と考えればまぁ、いいのでは。文章的にそうも読めますよ。



(基本:午前・問47)

オブジェクト指向に関する記述のうち、適切なものはどれか。

  • ア オブジェクト指向モデルでは、抽象化の対象となるオブジェクトの操作をあらかじめ指定しなければならない。
  • イ カプセル化によって、オブジェクト間の相互依存性を高めることができる。
  • ウ クラスの変更を行う場合には、そのクラスの上位にあるすべてのクラスの変更が必要となる。
  • エ 継承という概念によって、モデルの拡張や変更の際に変更部分を局所化できる。

(解答) エ

(コメント)

nope まぁエ。でも、文章はどことなくおかしいです。
「概念によって...局所化できる」とありますが、継承の概念だけではこうしたことの実現は不可能。「継承の機能によって」もしくはシンプルに「継承によって」ですね。
更に言えば、拡張の際には「変更」ではないのですから、「モデルの拡張や変更の際に変更部分を...」は、「モデルの拡張や変更の際に、追加・変更部分を...」でしょう。もっとも、これは細かすぎるか?



(DB:午前・問22)

オブジェクト指向データベースにおけるオブジェクト識別子(OID)に関する記述として, 適切なものはどれか。

  • ア オブジェクト識別子が異なれば,そのオブジェクトの属性値も異なる。
  • イ 関係データベースの候補キーに相当する。
  • ウ 個々のオブジェクトの型を直接識別できるようにユーザが設定する。
  • エ システムが扱う一種のアドレスであり, ユーザが直接扱わないのが普通である。

(解答) エ

(コメント)

nope 「オブジェクト指向データベースにおける」というふうに限定している意味がどこにあるのか今ひとつ不明ですが、まあいいでしょう。エです。
えせスピーカー Oracle でも OID があるんですよ、じつは。で、さらにオブジェクト参照というのもあって、これは結局OIDを使って JOIN するわけです。ということで、「オブジェクト指向データベースにおける」って言ってるんでしょう。じゃないと、イも正解になりますから。っていうかこんな問題つくるほうが間違ってる。
red sky スピーカーさん、OIDがOracleにあるとのことですが、昔のOracle(8より前)でもあるのでしょうか?
Oracleは8からエンジンがORDB化されているんですよね?
avi エの"システム"が"DBMS"のことなら、エだと思いますが、OSなどもっと大きい意味でのシステム、の意味なら"DBMS"が知ることはできませんよね。
ってことで、"イ"に一票。"候補キー"ってのが、、、
nope ちょっと待った。"候補キー"は、「タプルを一意に持定することができる属性の組合わせ」なので、やはり変では?。("名前""生年月日")などとしたりするので。"主キー"ならまだしも。
avi ちゃうちゃう(関西風)
"候補キー"は「タプルを一意に持定することができる属性」だと思います("組み合わせ"ではないはず)。
でもって、"主キー"は"候補キー"のなかから意味のあるものを選んだものです("主キー"は"候補キー"を継承 :-) )
問題はRDB と ODB のマッピングに関わるのでややこしいですが、私の認識ではODBにてオブジェクトを一意に認識できるものであればそれは関係データベースでの"候補キー"といってよく、OIDの他、属性値である社員番号なんかも"候補キー"といえます。ここであえて"主キー"としなかったあたりに出題者の渋さを感じたのですが、いかがでしょう?(なにを"主キー"にするかは開発者が決めるもので、OID = 主キー、とすると、DBMS開発者的にはよいが、アプリケーション開発者的には…)
えせスピーカー red sky さん、そのとおり、Oracle8i からの機能です。このOracleのOIDはなんと、主キーをOIDとして利用できる、つまりユーザが直接指定できるのです。というわけで、RDBを含めてしまうと、エの回答にならなくなってしまいます。また、"システム"の記述ですが、ODBによってはメモリアドレスをOIDとして使っているものもあります。で、その場合、OSのページスワップのタイミングで2次記憶とのデータやり取りをしてます。なので、OSを含んでもよいのでは?ただ、"候補キー"は必ず属性の組み合わせである必要はないでしょう。主キーは候補キーのなかの一つなのですから。
えせスピーカー 自分はどう答えたかなぁ。ひとつ問題点を発見。候補キーは空値を許すけど、OIDは許しません。これをなんとする?
スマイリー 候補キーに空値がOKとは知りませんでしたが、この問題では"OIDはRDBの候補キーに相当"という話しであって、OIDが空値を許さない、というのはOIDそのもののお話し。そう取れば別に良いのでは。
えせスピーカー "相当"の考え方が微妙ですが、RDBの候補キーに定義されている特性をOIDが満たしているかと考えるのが普通でしょう。
rope これ以上は言葉の問題になりそうなので深入りは止めますが、"適切なもの"という題意からみて、そんなに"不適切"な記述ではないような、、、(鯨のひげは人間の歯に相当、、、なーんて)
それと候補キーに関してちょっと見ましたが、空値を許すというのはやっぱりないのですが。(候補キーが空値だと、一意に行を判別できなくなるので"候補キー"の定義から外れますよね。もっとも、空値が該当列中で唯一ならOKですが)
out うーん、だからこういう問題は間違ってると思うんだけどなぁ。アとウは間違いだってすぐわかるけど、イとエのような微妙な場合はどちらがより適切"っぽい"かを考えるしかないような気がします。とすると、エのが適切っぽいかな。
あと、候補キーについて、少し前の話にもどりますが、候補キーは「タプルを一意に持定することができる属性の集合」であって、複数の属性から構成される候補キーには空値がはいることを許します。逆からいうと、キー制約として主キーは候補キーでかつ空値を許さないことであることからして、候補キーが空値をとりえるものとしているでしょう。
pwd (本題とは関係ない話です、、、)うーーん、やっぱり候補キーが空値OKってのが見つからない、、、どっか参照になるところ教えていただけますか?
pwd (ふと、気づく)よく読むと、"複数の属性から構成される候補キーには空値がはいることを許します"、ということだったのですね。
この場合、"複数の属性の集合=候補キー"となるので、候補キーが空値、というわけではありませんよね。候補キーを構成する属性のひとつが空値なだけです。また、候補キーは極小集合でないといけないので、無制限に空値が許されるわけではありません(これは少し余談)
で、話しはもどりますが、"複数の属性の集合"と"OID"が対応する関係と考えていただければ、OIDは空値を取らない、という前提のもとでも"OIDが RDB の候補キーに相当"というのもOKですよね(RDB的には候補キーである"複数の属性の集合"が空値であることまで許していないはずですから) 
えせスピーカー 候補キーが空値を許すって言うのは SQL92 からみたいですね。というのも、SQL92ではUNIQUE の指定の時にかならずしも NOTNULL 指定がいらない、つまり一意に識別される属性にもNULLが許されるということになっています。このあたりは、MySqlなりPostgresなりの文献を参照して下さい。つまりこれは候補キーに空値が許されることだと思うのですが。
で、また"相当"の定義にもどることになる。
??? うーーん、"UNIQUE 指定時に NULL が許される"、という話しと、"候補キーにNULLが許される"ってのは別個の話しですよね。
UNIQUE 指定は、"その要素のもつ値が、テーブル中で唯一である"、ということを示すものであって、"その要素により、テーブル中の行を特定できる"、という意味ではないですから。
候補キーにとって、UNIQUE であることは必要条件ですが、十分条件ではありません。
ってことで、やっぱり "候補キーには空値は許されない"、と思います。
#候補キーの要素中、NULL値をとる行が唯一であれば、(数学的に空値っ て何を示す?、って話しもありますが)それはOKかもしれません :-)
??? ん、ということは、候補キーがNULL値であってもよい場合があるって言ってません?
??? (まぁ、上の話しはあくまでいちびった余談ですので、、、一応説明します)

候補キーはその定義から、とあるテーブルRにおいてある属性Kが候補キーであるとは、2つの異なる行s, r に対して、s[K] != r[K] であることが条件とされています。

従って、属性Kにおいてnull 値が唯一であれば、この条件は満たされることになります。

この場合、
  1. 単に候補キーでも null がOK、というわけでなく、同時にnull 値をとるのが唯一の行であることが保証されていなければならない。
  2. そもそも null 値をさも"通常の値"のように扱ってよいのか、という数学的な問題がある。

ってことで、スマイリーつきの余談として書いたものです。

なので、主張としては"候補キーには空値は許されない"、で、"この問題の答えとしてはイ"です。
えせスピーカー ちょっとまった、それは議論が飛躍し過ぎでしょう。長くなると思いますが、整理&文献の紹介をします。すでにこのスレッドだけ非常に長くなってますけど、、。

まず、選択肢アとウについてはいいですね。全部について説明するのも大変なので。イとエについて、適切でないというポイントと適切であるというポイントをあげましょう。
では、私の主張:

イが適切でない点
- 候補キーは空値が許されないと明確に規定されていない
候補キーのその行が一意に識別される属性とされているだけで、主キーのように制約になっているわけではない

- 候補キーはそのテーブル内での行の一意性を保証するのみである
候補キーはテーブル内での一意性を保証するが、データベース全体にわたる識別性を保証するものではない

- 候補キーは値によってその行を識別する
候補キーはデータの値の一意性を保証するがOID はデータ値としての意味を持たない

エが適切である点
- OIDは本来ユーザが指定するものではない
OIDはシステム内部でふられたオブジェクトに対する識別子である。

- OIDはアドレスと考えることができる
ODBではクライアントキャッシュを用いる方法が一般的であるが、クライアントのメモリ上ではポインタが使われる。OIDはこのポインタと互換性を持つ

文献:
ODMG 3.0 ISDN 1-55860-647-5p17
2.3.2 Object IdentifiersNote that the notionof object identifier is different from thenotionof primary key in th relational model. Arow in a relationaltable is uniquely identifiedby the value of the column(s) comprisingthetable's primary key. If the value in oneof those columns changes, the row changes its identity and becomes a different row.Eventraceability to the prior value of the primarykey is lost.

The Object Database Handbook ISDN 0-471-14718-4 P8
Characteristics of OIDs
- OIDs are independentof the data contained in the object.The internaldata values are not used to generate identification.
- OIDs are generated by the object system.Users or programs have no control over identification.
- OIDs last the lifetime of the object. Identificationof the object never changes even when thedata contents may change.


以上、ふぅ。
??? こちらも一応、候補キーに関する記述も引用しておきます。
(http://www.ish.ic.kanagawa-it.ac.jp/sotsuken/R95/yamada/part3.html の 3.6 から) 引用

引用ここから-----

R(A1,A2,…,An)をリレーションスキーマとし、K={Ak1,Ak2,…Akp}(1≦k1<k2<…<kp≦n)を属性の集合とする。このときKがRの候補キー(candidate key)と呼ばれるのは次の二つの条件を満たすときである。

?RをRの任意(時刻)のインスタンスとする。このとき、

(∀t,t’∈R)(t[K]=t’[K]⇒t=t’)

ここに⇒は論理含意(logical implication)を表す。

?Kからその属性を一つでも欠落させると、もはや?の性質は成立しない。
つまり、KがRの候補キーと呼ばれるにはRのどのような(時刻の)インスタンスRをとってきても、そのいかなる異なる2タップルのK値は等しくない。つまり等しくしなければそれらは同一のタップルであるときのみ、そしてKはそのような性質を満たす極小の属性集合であるということである。この意味では候補キーとはタップルの唯一識別子(unique identifier)という。換言すれば候補キーとはタップルの唯一識別能力を持つ極小の属性集合である。

引用ここまで-----

ということで、ここで強調したいのは、
-- 候補キーにより、データを一意に認識できる
ということ。

この意味からは"OID は 候補キーに相当"って言っても良いかな、と思います。

一方、えせスピーカーさんの

> 候補キーはテーブル内での一意性を保証するが、データベース全体に
> わたる識別性を保証するものではない

と、

> 候補キーはデータの値の一意性を保証するがOID はデータ値として
> の意味を持たない

には納得。また、ODMG の引用部分(Primary Keyとの違い)も納得で、確かにイの答えではそのあたりのことをカバーできておらず不適切なように思います。

その一方でエが不適切と思う点は、"システムが扱う一種のアドレスであり"という記述。

このシステムが DBMS のことであればOKですが、普通ににシステムと捉えた場合、おかしいですよね。ODMGの定義でも"ObjectSystem"が割り振るとありますし、システム(普通はOS?)が管理するポインタをOIDとして使用しているとしても、それは実装上の話。
システム(OS?)が管理しない何がしの数字をDBMS で OID として管理してもOKということを考えると、この点がエの答えにおいて不十分なように感じます。

cwd 普通にシステムととらえたときに、なぜ OS となるのかが疑問です。システムエンジニアとか、システムテストとかの"システム"ってOSじゃないと思いますけど。普通に考えれば個々のアプリケーションを統合したコンピュータで情報処理を行うしくみ全体となるのでは?
あと、
>システム(OS?)が管理しない何がしの数字をDBMS で OID として管理してもOK
上記の意味がよくわかりません。



(DB:午前・問49) (EB:午前・問49)

機能単位に分割したアプリケーション(オブジェクト)を分散システムで実行・通信・管理する仕組みであり,OMG(Object Management Group)で標準化が行われているものはどれか。

  • ア CORBA
  • イ JAVA
  • ウ OSI
  • エ WWW

(解答) ア

(コメント)

nope 異機種分散環境上で、オブジェクトが互いに通信を行うための仕様ですね。
説明はなんかピントがずれてるけど、正解はア。
「機能単位に分割したアプリケーション(オブジェクト)」と言い切ってしまうところがすごい。



アンケートにご協力お願いいたします
記事の内容を5点満点で評価してください。
1点 2点 3点 4点 5点

© 2001 OGIS-RI Co., Ltd.
Prev Index Next
Prev. Index Next