$Id: oose.txt,v 1.9 2003/12/05 14:25:28 katsu Exp $ 注意： この文書「OOSE 訳本の変なところ集」は既に時代遅れなものとなっています。 OOSEの訳本には、 ・1995年にトッパンから発行された旧訳本 ・2003年にエスアイビー・アクセスから発行された復刻版 の2種類があります。この文書で指摘した問題点は、1995年の旧訳本に対する ものです。復刻版の発行の際、この文書で述べられた問題点は精査され、その ほとんどは改定として取り込まれました。 復刻版についての情報 http://katsu.watanabe.name/oose/ も併せて参照してください。 ---------------------------------------------------------- OOSE 訳本(*)の変なところ集 contributors:(所属は1995年当時) 中山秀樹さん（富士ゼロックス情報システム） 渡邊克宏（ＳＲＡ） (*) 原著 Ivar Jacobson; "Object-Oriented Software Engineering"; ISBN 0-201-54435-0; Addison-Wesley; 日本語訳「オブジェクト指向ソフトウェア工学OOSE」; 西岡利博・渡邊克宏・梶原清彦監訳; ISBN 4-8101-8066-2;トッパン この(旧)訳本は既に絶版になっています。この文書で指摘されている 問題点を含めて大幅に訳を改めた復刻版が発刊されています。復刻版に ついては http://katsu.watanabe.name/oose/ を参照してください。 このメモは、OOSE の訳本の、主に 1,2,4,6,13章を見て気がついたことを気楽 に書き留めたものです。渡邊は訳本の監訳者でしたが、このメモは公式の訂正 表のようなものは意図していません(訳本についての公式の窓口は、訳本の p.486 にあります)。本よりも下の主張の方が正しいことは確認しておらず、 今のままで正しい所もあるかもしれません。読み飛ばした節もあります。原文 と見くらべた所もありますが、その際の原書は 4th edition ではない古いも のです(訳は 4th edition を元に行なわれました)。4th edition ではたいそ う書きかわっているので、あてにできるか不安があります。 http://katsu.watanabe.name/review/oose.txt に最新版を置くことにしま す。引用・複写・再配布は自由です。このメモへの追加、誤りの指摘や御意見 御感想を歓迎しますので、渡邊克宏 まで連絡を下さい。 -10L というのは、ページの最後から 10 行目という意味です。 p.20 -10L < 規模の調整がきくようなシステムでは、 > 大規模なシステムでは sizable の意味の勘違い。 p.23 -5L < コード作成段階の生産性が、開発工程全体の生産性に大きく影響するので、 < 再利用はコード化段階においても適用できる。 since it can influence の it は、「コード作成段階の生産性」ではなく、 the necessity of reusability もしくは reusability(コード作成段階での 再利用性) のことの気がする。 p.33 +4L : compilation in cross-reference editors(browsers) < ブラウザ上では翻訳された形で 意味がよくわからない。 > ブラウザ上では埋め込まれたクロスリファレンスの形で p.74 -4L < 機能/データ指向 前の訳語(p.69 4.2節+2L)では「機能とデータを分ける方法論」となって いたが、訳語を合わせなくてもわかるか？ p.87 図5.7 Smalltalk/V の例 < (4) aperson > (4) aPerson Eiffel の例 < (5) aperson.Jump; > (5) aPerson.jump; p.95 -4L < aPersonjump > aPerson.jump p.97 +1L < MaleBody. new > MaleBody.new p.97 +9L < friend :=name > friend := name p.102 < [Brook 1987] > [Brooks 1987] p.106 囲み記事+1L < 数学とコンピュータ科学の異なった領域にアナロジーを導入する。 間違いではないが、draw analogy は「類似性を説く」という時の collocation。different areas の different は、いろいろなという 意味だと思う。 > 数学とコンピュータ科学のいろいろな領域の間の類似性を説明する。 p.106 囲み記事+7L < 概念はそれ自身を表現するためのツールであり、 それ自身とは、概念自身のこと？このあたりは 4th ed で変わったのか？ p.106 囲み記事+11L < もし問題が有限時間内にとけるなら、それは決定的であると呼ばれる。 > 決定可能であるといわれる。 原書からして間違っている。問題がとけるかどうかは deciability(決定可能性) のこと。determinism(決定性)は、例えばチューリングマシンの動作とか、 PROLOG での推論で適用できる公理が複数ある(非決定性)とか、一般に何かの 戦略に alternative があるかどうかという話。 < (この情報空間はしばしば NP 完全集合と呼ばれる) 全くの誤り。決定可能であることと NP 完全とは関係ない。 NP 完全とは、NP(非決定性チューリングマシンで多項式時間)の中の、 「最も難しい」問題をいうのだった。つまり、 (1) NP完全には、(NP の中の)易しい問題は入っていない。 (2) NP完全には、NP よりも難しく decidable な問題は入っていない。 という２点で、NP 完全なクラスを情報空間とするのは明らかに不適格である。 などなど、ここ以降のチューリングマシン・計算量のクラス(NP とか)・ 決定可能性に関する議論は(「用語を非常に厳密に扱ったわけではない」という 断り書きを考慮に入れてもまだ)怪しい。 p.107 -21L < この問題を避けるために、λ計算に簡約規則を導入するが、 ここでいう簡約規則(原書では reduction rule)というのは、項書換え系の 「書き換え規則」のことをいっていると思う。λ計算の文脈で「簡約」規則と いうと、どうしてもβreduction とかを思い浮かべがちなので、書換え系の 方の話だと強調してはどうか。 > この問題を避けるために、λ計算に書き換え規則を導入するが、 「λ計算に書き換え規則を導入する」という言い回しはしないかもしれないが、 その辺はよしなに... p.108 -7L < 発見的教授法(ヒューリスティクス) 初めて聞く言葉ですが、heuristics の訳語なんでしょうか。わかりやすく 「経験的知識」ぐらいでいいんじゃないでしょうか。 p.110 +9L < 大部分のプロジェクトの種類では、 > 大部分の種類のプロジェクトでは、 あるいは > 大部分のプロジェクトでは、 p.112 -13L < 形式ではない。 > 形式的ではない。 p.114 +8L < 開発者の投入が問題になる > 開発者をどのように投入するかが問題になる。 直さなくてもわかるとは思うけど。 p.115 -9L < 他のモデルで総合的に間違っていることもある。 > 他のモデルでは全く間違っていることもある。 または > 他のモデルには全くそぐわないこともある。 p.116 +5L < OOSE で設計される最初のモデルは、発注者の機能要求によって < 統合的に決定される。そしてそれは、(単純な追跡可能性によって) < 変更が局所化される結果となる。この変更の局所性は、どの程度 < ユーザの見通しが変更されるかに依存する。 total(統合的)に -> それのみによって完全に。 how(どの程度) -> どのように。 as 以下は理由を表している。 ユーザの見通しがどのように変更されるかに依存しているのは、 「変更の局所性」ではなく「変更」だと思う。 結局ここは、 OOSE のモデルを最初に作る時、それは発注者の機能要求だけから 完全に定まる。そしてその後の変更も局所化されている。 なんでかっていうと、モデルがどのように変化するかは、 ユーザの見通しがどのように変化するかと直接連動していて、 さらにどの部分が変化するかは明確な追跡可能性からわかるから。 ということをいいたいのでは？ p.117 +11L < この処理は、実行される複数の行動からなる。 > アクティビティからなる。 p.118 -1L < このとき、ユーザインタフェースのプロトタイプが完全なツールである。 > 最も有効なツールである。 p.119 +5L < そして、このオブジェクトモデルは要求モデルの開発の支援として < 利用できなければならない。 ここの should は「でなければならない」（義務）じゃなくて、 「であるのが当然だ」とか「のはずである」（蓋然性）を表していると 思う。 この直前の行の「ならない」も同じかもしれない。 p.119 -7L < ドメインオブジェクトモデルが詳細化されたオブジェクトモデルの中で < 使われる場合には、ドメインオブジェクトによって表現される。 意味がよくわからない。 p.121 +3L < １次元だけでオブジェクトを表現するという方法がある。 > オブジェクトに１次元分の概念だけを受け持たせるという方法がある。 ここはオブジェクトをどう表現するかという話ではなくて、 分析モデルを(オブジェクトで)どう表現するか、そのためには オブジェクトにはどれだけの役割が必要かという話。 p.121 -7L < それぞれのオブジェクトは上記の３つの次元のうちの少なくとも < ２つの次元で表され、 > ２つの次元の概念を表現しており、 オブジェクトがどの次元を表現するかという話が前のパラグラフから 続いている。 < 特に１つの次元と関係を持っている。 > 特に１つの次元と深い関係を持っている。 p.121 -4L < オブジェクトの種類にはそれぞれ異なる目的がある。 > オブジェクトは種類に応じてそれぞれ異なる目的を持っている。 p.122 -12L < １つあるいは２、３の use-case に限定される典型的な機能は < 制御オブジェクトに置かれる。 > 典型的には、１つあるいは少数の use-case に限定される機能は > 制御オブジェクトに置かれる。 p.122 -4L < 制御オブジェクトにおいた振舞い > 制御オブジェクトにおける振舞い p.123 +2L < これはオブジェクト(これをブロックと呼ぶ)が問題ドメインの中に < 相対物を持つものであるというオブジェクトベース技法である。 > これはオブジェクトベースの技法であり、オブジェクト(その > プロジェクトではブロックと呼んでいた)がほとんどの場合に > 問題ドメインのオブジェクトと対応していた。 p.123 +7L < トランク(交換中の電話回線) > トランク(交換機間を接続している回線) p.123 +11L < そして、ただ１つの use-case のために２３個の操作が追加されたことが < 分かった。 > ２３個もの操作が "!" は 4th edition ではなくなっているのかしら？それに What we found を 文頭にもってきているのは、強調の意図があるはず。 > そして分かったことは、ただ１つの use-case のために、なんと２３個も > 操作が追加されていたことだった。 （このあたりは古い原書と対応しないので、4th edition で書き変わったか？） < このように、操作は再利用できるわけではなかったし、 > このように、操作は必ずしも再利用できるわけではなかったし、 < 新しい use-case を追加する必要があった時、多くの場合、 > 新しく ふつうはこう書くと思います。 p.127 図6.19 < 口座預金 > 当座預金 p.127 図6.20 < 報告 > レポート 本文との対応 < 普通預金報告 > 普通預金レポート < 当座預金報告 > 当座預金レポート < 定期預金報告 > 定期預金レポート p.128 図6.21 < 報告 > レポート 本文との対応 p.129 図6.22 < 報告 > レポート p.130 図6.23 caption : thus, yielding that the analysis model will offer the use cases : of the system. < したがって分析モデルはシステムの use-case を提供するといえる。 ここの offer は、「提供する」ではわかりにくいから「表現する」では どうか？yielding も難しいけど「...を許している。...を可能にしている」 (compliant)という意味？ p.131 +16L < いくつかの関連の種類を用いて、 > いくつかの種類の関連を用いて、 p.131 +21L : as it is the problem which controls the architecture and not the : factors of the actual implementation environment. < 何がアーキテクチャを制御するのかが問題であって、実際の実装環境の < 要因は問題ではない。 which は「何が」ではなく problem にかかる関係代名詞では？ それから、後半の not は not the problem ではなく it is not the factors （前半の it is the problem との対比）ということの気がする。 > というのも(as)、結局分析モデルというのは(it is the problem)、 > システムのアーキテクチャの構造を左右する問題を語っているのであって、 > 具体的な実装環境につながる要因は含んでいない(it is not the factors) > のである。 という意味のように感じた。 p.131 +23L < 基盤システムの構造は > システムの基盤の構造は p.133 +14L : distributed hardware involving different operating systems < 開発者は、異なるオペレーティングシステムが動いている分散ハードウェア 分散ハードウェアという訳語は前衛的過ぎると感じた。 > 開発者は、異なるオペレーティングシステムが動いていて分散している > ハードウェア または > 開発者は、ハードウェアが地理的に分散していて各所で異なる > オペレーティングシステムが動いている状況 : a changeable protocol between the different nodes (not yet standardized) < 異なるコード間の(標準化されていない)変更可能なプロトコル < 異なるコード間の(まだ標準化が済んでいない)変更の可能性のあるプロトコル p.135 +12L < 実際には .h ファイルと .c ファイルの２つである。 C++ のファイル名拡張子は普通は .c を用いず、.cc とか、.C とか、.cpp とか だと思う。gcc は .c が通用するけど...。後の章では .cc という拡張子を 使っているようだ(p.225 -4L)。 p.136 +18L < この場合には、最初の段階でサブシステム間のインタフェースだけを < 指定することになる。 「最初の段階『で』」ではよくわからない。サブシステム間のインタフェースを 指定するという作業が、開発プロセスの最初の段階に挿入されるのかのごとく 読めてしまう。 > 最初の段階から ところで、to extract the interfaces to a aubsystem level という文 (ブロックからサブシステム・ブロック間のインタフェースからサブシステム間の インタフェースへと抽象度が１段上がることを説明している)は 4th edition では なくなってしまったのでしょうか。 : whereas inside each subsystem, the development team can work with : the blocks < これによって、開発チームは...ブロックで作業できる。 不自然。 前の文 - 「これによって」 -「開発チームはブロックで作業できる」 という関係だとはいっていないと思う。 前の文 - その一方で(whereas) - 「開発チームはブロックで作業する」 という関係だと思う。 p.136 -11L : The information space of this model is the one that the programming : langauge uses < このモデルの情報空間はプログラミング言語で使われているものである。 > このモデルの情報空間は、利用するプログラミング言語の情報空間である。 プログラミング言語Lの情報空間とは、L が定義する「(形式言語理論でいう) 言語」それ自身(文法上 well formed な文字列の集合)のこと。 p.136 -5L < この記述がどのように見えるかということについては > この記述がどういう形式をしているかについては、 p.139 +3L < 設計モデルでは、ブロックはインタフェースを明確に指定するための < use-case とブロック間のやりとりを用いて指定される。 > 設計モデルでは、use-case モデルを用いてブロックのインタフェースと > ブロック相互のやりとりが指定され、詳細化が行なわれていく。 p.139 -2L < 単体テストを行なう時には、低レベルのオブジェクトが最初にテストされる。 > まず単体テストによって、低レベルのオブジェクトがテストされる。 p.149 +18L アイテムの返却 use-case の記述 < それはシステムによって計測される > システムによってそれは計測される 162 ページの記述との対応 p.149 -13L < 顧客の合計数が計算され、 > 顧客の返却物の合計数が計算され、 p.162 +13L < 受け取りボタン > レシートボタン 149ページのユースケース記述との対応 < 顧客の合計数が計算され、 > 顧客の返却物の合計数が計算され、 p.162 +18L < この種別の合計 > この種別の合計金額 p.162 +19L < 金額最後に > 最後に p.162 -11L < 顧客のためのパネル > 顧客パネル 図 7.14とのあいだの訳語の統一 p.162 -9L < 顧客のためのパネル > 顧客パネル p.162 -7L < オペレータのためのパネル > オペレータパネル 図 7.14とのあいだの訳語の統一 p.165 -4L < 顧客のためのパネル > 顧客パネル 図 7.14とのあいだの訳語の統一 p.166 図7.18 < 顧客のためのパネル > 顧客パネル 図 7.14とのあいだの訳語の統一 また、図7.18 では、 (a) 「スタートボタン」インタフェースオブジェクト (b) 関連「スタートボタン[1]」（「顧客パネル」から「スタートボタン」 オブジェクトへ向かう） の２つが欠けている。 p.168 +6L < 対話主体な制御 > 対話主体の制御 「計算主体の制御」という訳語との対比 p.169 +3L < それはシステムによって計測される。 > システムによってそれは計測される。 162 ページの訳との統一 p.169 +7L < 顧客が受け取りボタンを押すと、 > (段下げ)顧客がレシートボタンを押すと、 162 ページの訳との統一 < 顧客の合計数が計算され、 > 顧客の返却物の合計数が計算され、 p.169 +13L < 最後に、... この行は段下げをする。 p.169 +20L < 底の幅 > 底回りの幅 図 7.21 との間での訳語の統一 p.170 図7.21 前のページとの間での訳語の統一 < 首周り > 首回り < 底周り > 底回り 「カゴ」から「メートル法」への関連のところ < 長さ > 奥行き < メートル法 > メートル 属性の型をいっているのだから。 p.175 -19L < それはシステムによって計測される。 > システムによってそれは計測される。 162 ページの訳との統一 p.175 -17L < 顧客の返却物の合計数は増やされ、同様にそれぞれのアイテムの種別ごとの < １日の合計数が増やされる。 > 顧客の返却物の合計と１日の合計数のそれぞれのアイテムの種別ごとの > 数が増やされる。 162 ページの訳との統一 p.175 -8L < 最後に、... この行は段下げをする。 p.178 図7.26 < 顧客のためのパネル > 顧客パネル p.178 -11L,-7L,-6L,-5L < 顧客のためのパネル > 顧客パネル 図 7.14 とのあいだの訳語の統一 p.181 図7.27 < 顧客のためのパネル > 顧客パネル 図7.14 との間の訳語の統一 p.189 図8.3 < 顧客のためのパネル > 顧客パネル 図 7.27(図7.14) との間の訳語の統一 p.189 +3L < [Yordon and Constantine 1979] > [Yourdon and Constantine 1979] p.190 図8.4 < 顧客のためのパネル > 顧客パネル 図8.3(図 7.27,図7.14) との間の訳語の統一 p.191 図8.5 < ファイルマネージャ > ファイル管理 p.192 の 6 行目との間の訳語の統一 p.195 図8.7 < 顧客のためのパネル > 顧客パネル 図8.4(図8.3,図 7.27,図7.14) との間の訳語の統一 p.195 +8L < この拡張関連はアラームにあるものである。 > この拡張関連は use-case アラームにあるものである。 p.199 図8.9,図8.10 < 顧客のためのパネル > 顧客パネル 図8.4 との整合性 p.200 -15L < それはシステムによって計測される。 > システムによってそれは計測される。 162 ページの訳との統一 p.200 -12L < もし受け付けられなかったならば、 この行の先頭で改行や段下げをせず、前の文につなげる。 p.200 -10L < 顧客の合計数が > 顧客の返却物の合計数が p.201 図8.11 < 顧客のためのパネル > 顧客パネル 図 8.10 などとの整合性 p.202 -15L < １つある。 > １つである。 p.204 図8.13 < 荷運び台が移動できるか調べる > 荷運び台が移動できるかどうか調べる 図 8.14 との整合性 p.208 図8.16 < 顧客のためのパネル > 顧客パネル 図 8.9 などとの整合性 p.210 図8.17 < 顧客のためのパネル > 顧客パネル 図8.9 などとの整合性 p.211 図8.28 右端が一部欠けている < total Value=val*of > totalValue:=val*noReceived < print on str(name, < deposit Value, total > print on str(name, > depositValue, totalValue) < sum:=sum+total V > sum:=sum+totalValue この辺、英語のままだけど、読む人は本文との対応がとれるのだろうか... p.224 +16L < TotalNumber 属性を持つ > totalNumber 属性を持つ p.224 +18L < class Inserteditem : public Link. { > class InsertedItem : public Link { = = < DepositItem *returnedltem; > DepositItem *returnedItem; = p.225 -2L < void ReceiptBasis::insertltem(Depositltem *di) { > void ReceiptBasis::insertItem(DepositItem *di) { = = p.226 コード +1L < Inserteditem *ii = new lnsertedltem(di); > InsertedItem *ii = new InsertedItem(di); = = = +5L < Inserteditem *ii = (lnsertedltem*)itemList->first(); > InsertedItem *ii = (InsertedItem*)itemList->first(); = = = +7L < if (ii->getltem() == di) { > if (ii->getItem() == di) { = +11L < ii = (lnsertedltem*)ii->nextLink(); > ii = (InsertedItem*)ii->nextLink(); = = +14L < Inserteditem *ii = new lnsertedltem(di); > InsertedItem *ii = new InsertedItem(di); = = = +23L < Inserteditem *ii = (lnsertedltem*)itemLisf->first(); > InsertedItem *ii = (InsertedItem*)itemList->first(); = = = = +25L < name = ii->getltem()->getName(); > name = ii->getItem()->getName(); = +26L < value = ii->getltem()->getValue(); > value = ii->getItem()->getValue(); = +30L < ii = (lnsertedltem*)ii->nextLink(); > ii = (InsertedItem*)ii->nextLink(); = = p229 コード +11L < Item := getltem; > Item := getItem; = +13L < CASE Item : ltem_type OF > CASE Item : Item_type OF = +14L < Can: newCan(ltem) > Can: newCan(Item) = +15L < Bottle: newBottle(ltem) > Bottle: newBottle(Item) = p.269 +1L < put(e,queue,preemptive,priority, length) > put(e,queue,preemptive,priority,length) p.316 図13.1 表題 < ACM 倉庫管理会社 > ACME 倉庫管理会社 p.320 図13.5 < 顧客からの品物引き出し注文 > 顧客による品物の引き出し指示 本文(p.321)との対応 p.325 -5L < 顧客による引き出し指示 > 顧客による品物の引き出し指示 p.326 +8L < 顧客による引き出し指示 > 顧客による品物の引き出し指示 p.328 -2L < 倉庫間の手動配送の実行 「の実行」の部分は、ユースケース名の一部ではないので、 通常の明朝体にする。 p.331 -8L < 積み込みステップ7 > 荷降ろしステップ7 p.332 図13.12 < トラック便運行運行 > トラック便運行要求 p.333 図13.13 < 場所と数量[M] > 場所と数量[1..M] p.334 図13.14 「計画対象トラック便」関連の向きが逆 p.336 +13L < ・倉庫間の手動配送 < ・顧客による品物の引き出し指示 < ・倉庫内での品物の運搬 これらはユースケース名なので、太明朝体がふさわしい。 p.337 -8L < 1、2、5、6、7は、倉庫内輸送役で処理できるだろう > 1、2、5、6、7は、倉庫間輸送役で処理できるだろう < 一方、ステップ 3、4 では、倉庫間輸送役... > 一方、ステップ 3、4 では、倉庫内輸送役... p.339 図13.17 表題 < use-case の初期化部分のビュー > use-case の初期化の部分のビュー 図 13.18 の表題の表現法と統一。 p.340 図13.19 表題 < 積み込み部分のビュー > 積み込みの部分のビュー 図 13.18 の表題の表現法と統一。 p.341 図13.20 < 積み降ろし > 荷降ろし