第1章 実世界のモデル化と形式化 1.モデルとその形式表現 2011-02-15 第1章　実世界のモデル化と形式化 1.モデルとその形式表現 太田守重 morishige_ota@kkc.co.jp

ここで学ぶこと 私たちは，身の回りの環境や世界を認知し，知識として記憶し，それを使って判断して行動する． 知識は，認知の結果としての実世界のモデルともいえる．これを他者に伝えるには，一般には自然言語を使用する．しかし，自然言語には多義性があるので，表現に曖昧さが残る．そこで，誤解が起きないように，厳密に定義されたルールに従う，形式化された言語（スキーマ言語）を使用することが望ましい．特に情報ネットワークを通じて情報交換するシステムには、これが求められる。 ここでは，実世界に生起消滅する諸現象（地物）を，どのようにモデル化し，それをどのように形式的に表現するかを学ぶ．

知識の形成（ピアジェ） シェマ（知識） 観察 新たな概念を含むシェマ 同化と調節 発達したシェマ ピアジェ（Jean Piaget, スイス, 心理学者, 1896-1980）の発達理論（均衡化説）によれば，人間が保持している知識の集まりをschemaといい，これは，環境との関係において形成される知識の枠組みとされる．人間は実世界に起きるモノやコトをとらえると，すでにもっているschemaを使って識別するが，その働きを「同化」という．しかし，外界の事物を既存のschemaではうまく同化できない場合に，それを外界に合わせて変化させることによって順応しようとする．この働きは「調節」と呼ばれる．ピアジェはschemaの操作（同化と調節）によって，知識の枠組みが広がるとした。 同化と調節 発達したシェマ

知識の共有 Aさんのシェマ Bさんのシェマ 共通の知識は、共通の構造をもつ。 その構造は、関係者が共有する、構造記述のための知識に従う。 この知識は、知識についての知識、つまりメタ知識である。これが共有されれば，コミュニケーションが可能になる． 個々人が獲得した知識を，互いに交換するためには，関係者の間で共通のコミュニケーション手段をもたなければならない．一般にこの手段は言語と呼ばれるが，その構造，つまり語彙と文法の知識を，関係者が共に有することがコミュニケーションの前提となる．この，語彙と文法は，知識を伝達するための知識，つまりメタ知識である． Cさんのシェマ

メタモデルとその共有のプロセス モデル：興味の対象となる実世界に出てくる実体の言語表現 メタモデル：モデル表現のためのルールを記述するモデル モデルの共有はメタモデルの共有が前提 共有には合意が前提 関係者が合意したルールを標準という 標準化 （de facto, de jure） 例えば、国際標準化機構 （International Organization for Standardization） ISO などの標準化組織が de jure 標準の審議を行い、国際標準を制定。日本を含むWTO加盟国は、原則としてISO標準を国内標準としても使用し、政府調達ではこれに準拠する（ことになっている）。 複数の人にとって，興味の対象となる実世界の範囲を「論議領域」という．その中に含まれる実世界の現象の実体，つまり概念の言語表現を「モデル」という．このモデルを表現するためのルールの記述は，モデルのモデル，つまりメタモデルと呼ばれる．論議領域を共有する人々が，モデルとなる知識を共有し，発展させるためには，メタモデルの共有が必須である．しかしその前提として，一定のメタモデルの共有に関する合意が必要となる．例えば，今日の国際会議の多くは英語を使うことが多いが，これは，英語の語彙と文法（英語のメタモデル）を使用するという合意が成立していることを示す． ところで，例えばネジのような工業製品の場合，その仕様が世界共通であれば，どこの国でも，自分の機械に適合するネジを手に入れることが可能になる．つまり，国際的な合意がなされた仕様書，つまり国際規格があると，さまざまな分野のメリットが生ずる．そこで，国際標準化機構が＊＊＊＊年に創設され，工業製品のみならず，電子的な情報交換のための国際規格づくりを行っている．地理情報分野でも，１９９４年に専門委員会２１１が設置され，世界中の国や公的な組織が参加して，地理情報の交換や共用にための規格作りが行われている．日本も設立時から，投票権をもつparticipant memberとして，規格作りに貢献している． このような，規格は「公的な規格 (de jure)と言われるが，Windowsのように，多くのユーザをもつ仕様や製品は「事実上の標準（de facto)と言われる．

地物 地物(feature)：実世界の現象の抽象概念．地物は型またはインスタンスとして表現される．同じ性質をもつ要素の集まりを地物型という．地物型に含まれる要素を，その型の地物インスタンスという． （例） 地物型 河川 地表の窪みを沿って高所から低所に向かう水の流れ。名称，全長，形状で特徴づけられる 地理情報分野の規格を一般的に「地理情報標準」というが，その中で使われる最も基本的な用語の一つに「地物 (feature)」がある．地物は，実世界に生起消滅する現象の抽象概念である．そもそも，外界に起きる現象を二つの方式で認知していると言われている．一つは型（type），もう一つは実例(instance)である．目の前にある現象を見て，それは「川だ．」と言明するとき，その人は，「高所から低所まで水が流れている長い窪地」は「川」ということを知っているので，目の前で実際に起きている現象は「川」に違いないと考えたといえる．一方で，そのような現象は至る所にあり，目の前の川は，その一つの実例として「利根川」という名前をもつことを知っている人は「利根川だ．」と言うかもしれない．つまり，人間は，実世界の現象を抽象化して概念として覚えるときに，型，そしてその実例として，記憶すると考えられる． 地理情報標準では，実世界の現象の抽象概念を地物というが，地物は地物型または地物インスタンスとして表現されると考える．この考え方は，情報学の世界でも通常用いられている．例えば，プログラム言語において変数は，整数やブール値などの型をもつ，その型に従った値を使って計算が行われる． なお，地物という言葉は，日本においては明治時代から使われている言葉のようであり，元来軍事用語であった．その意味は「敵を隠蔽する遮蔽物」である．その後，地上に存在するものを地物というようになったが，空間のある部分を占め，人間の感覚でとらえることのできる形をもつ対象，という意味のほかに，人間が考えることのできる形のない対象（例：ものの役に立つ，あきれてものも言えない）という意味もある．つまり，実世界に生起消滅する現象はすべて，地物として抽象化するとしても差し支えないであろう． ちなみに「地形」という言葉は「孫子」や「日本書紀」に見られる古い言葉であるが，地理情報標準では，地形は，一定の地理的な範囲をもつ空間として，地物の一種として扱われる． Featureという言葉は，本来，実世界に存在するものを，ある側面からとらえた特徴を指す言葉であった．実世界の現象を抽象化するときは，対象物のもっている特徴全てを列挙するこはできず，またそのような努力をする意味もない．我々は必要な特徴を選択して，概念化する．その概念のことを，地理情報標準ではfeatureといっている．この言葉に対して，objectという言葉を使うべきという意見がある．しかし，情報学の分野ではobjectはある性質もったものの実例，つまりinstanceとして定義づけられることに留意すべきであろう （次のスライド参照）． 地物インスタンス 名称：C川 全長：約322km 形状：

スキーマ言語（UMLの場合） UML: Unified Modeling Language Grady Booch、James Rumbaugh、Ivar Jacobsonによって開発されたスキーマ言語．1997年11月にOMG (Object Modeling Group)によって標準として認定． クラス:同じ性質や条件をもつオブジェクトの類を示す概念（型と同じ）． オブジェクト:クラスに含まれる要素． 横浜ベイブリッジ （定義） クラス 河川や海を横断するための人工構造物 橋 関係者に共通的な規則を使って，形式的に表現したモデルをスキーマという．統一モデリング言語(UML)は，地理情報標準のルールをスキーマとして表現するために採用された言語である．ただし，UMLでは型(type)のことをクラス(class)，インスタンス(instance)のことをオブジェクト(object)という．UMLは単語の列で表現する一次元的な言語ではなく，２次元の図を使ってコミュニケーションを図る，グラフィック言語である． タワーブリッジ クラス（型） オブジェクト

UMLクラス図 UMLでは，クラス図を使って，クラスの定義，及びクラス間の関係記述を行う． クラスはその名称，属性及び操作で定義する．属性とは，そのクラス固有の性質のこと．操作とはそのクラスがもつ機能，または振る舞いのこと． クラス間の関係には，関連（集成，合成）と継承がある． クラスには，インスタンスをもたない抽象クラス，インスタンスをもつ具象クラスがある．最も抽象度の高いクラスをルートクラスという． 操作には多態性という性質がある． クラスには，属性の型を示すデータ型がある． クラス図の要素に定義には文章をつかう．

クラスの記法 クラスは3つの襴で記述する。 名前：クラスを識別するための「名前」 属性：その実体固有の性質 名前 　　例：量、質、状態、場所、時間、・・・ 操作：クラスの振る舞い（能動、受動） 　　例：道路の長さ（） 　　　道路の形状を示す線データから，道路の長さを計算し，値を返す 属性欄や操作欄は，もし属性や操作がない場合は，省略することができる。 道路 名前 名前：String 形状：GM_Curve 属性 延長計算() 操作 属性は，その名前と属性値が従うデータ型で示される． 操作は，一般的にはアルゴリズムで示されるが，クラス定義の中では，操作の名前（関数の名前），操作に必要なパラメータの定義（変数とそのデータ型），そして操作の結果の種類（戻り値のデータ型），つまりシグネチャで示される． 道路 道路 道路 名前：String 形状：GM_Curve 道路の長さ() 属性・操作を省略した記述 操作を省略した記述 属性を省略した記述

属性 道路 属性：クラスがもつ固有の性質 属性名と属性の型で示す。 属性 属性値が従うデータ型 基本データ型 例： String（文字列），Integer(整数)， Float, Long（実数），Boolean（真偽値） コレクションデータ型 集合型（Set） 　　有限な要素をもつ集合。重複するインスタンスを含んではならない。 順序型（Sequence） 　　要素が順序をもつ集合。 名前[1..*]：String 種類：String 属性 属性名 属性の 多重度 属性の型 道路 名前：Set<String> 複数の名前を，順不同に列挙することができる 例：川越街道,国道254号線 属性の多重度については次のスライドでその詳細を述べる． 道路 種類：Sequence<Integer> 複数の整数を順序付けて並べることができる。 例：31.54, 78.98 この数字が逆になってはいけない。

属性の多重度 同じ種類の属性が複数あるときに使う 属性名の後の[ ]の中に記入 [最小値...最大値] 多重度が1の場合は省略 【多重度の表現】 同じ種類の属性が複数あるときに使う 属性名の後の[　]の中に記入 [最小値...最大値] 多重度が1の場合は省略 属性名：Set<属性型>との違い 属性名：Set<属性型> 1つの属性名に対し，複数の値が対応 属性名[多重度] 1つの属性名と一つの値が組になり，その組が複数個できる。 クラスA ：0または1 属性名[0,1]：属性型 クラスA ：1以上 属性名[1..*]：属性型 （* は複数を表す。n と記述することもある） 「,(カンマ)」で区切ることで離散値を指定し，「..(2つのドット)」で区切ることで範囲を指定する。 道路 名前：Set<String> 道路ID 1 インスタンス 名前 川越街道, 国道254号線 道路 名前[0..*]：String 道路ID 1 インスタンス 名前 川越街道 名前 国道254号線

クラス定義の手順 一般化 仕様化 自転車 所有者：文字列 使用目的：文字列 サイズ：整数 メーカー：文字列 使用者[1..*]：文字列 所有者：String 使用目的：目的コード サイズ：Integer メーカー：メーカーコード 使用者[1..*]：String 私の自転車は， 通学用で， 車輪のサイズが24inch， メーカーはBridgtstone， 妹や母が使うときもある。 クラスの定義は，観察，一般化，仕様化（形式化）の順番で行う．実世界に起きていることを観察し，自然言語で描写してみる．これによって，必要なクラス，その属性及びデータ型などが分かる．それをさらに，UMLの仕様に沿って形式記述することで，クラス定義ができる．また，その過程で，コードテーブルなど，属性の定義に必要となるデータ型の定義も行う． 目的コード 1 通学 2 通勤 3 遊び 4 スポーツ メーカーコード 1 Brightstone 2 PanaPana 3 RoadStar

操作 操作 インスタンスが実行する能動的及び受動的振る舞い 例：計算、解析、シミュレーション、・・・ 操作の記法 操作名（文字列） 引数（属性名：属性型の列） 戻り値（データ型） 操作は実際には，シグネチャだけではなく，実際に計算に使われるアルゴリズムが求められる．クラス図に表記ではそこまでは求められないが，何らかのプログラム言語を使用して，アルゴリズムを実装し，アプリケーションサーバなどに登録し，インスタンスから操作が呼び出せるようにするとよい． 例：建築物での操作 操作名(name) 引数（argument） 戻り値 (return value) 日陰（建築形状：立体、日付：グレゴリオ暦、時刻：日本標準時）：多角形

関連 関連: クラス間の対等な結び付き 役割名：関連先のクラスの役割を説明する名前 多重度：関連元クラスの1インスタンスに対して，関連先クラスのインスタンスがいくつ対応するかを示す数 関連の描き方 関連を持つクラス間を線でつなぐ。 役割名及び多重度をつける。 （多重度が「1」の場合は省略可） 【関連の多重度の例】 クラスB ：厳密に1 1 クラス同士の結びつきを示す関係には，大きく関連と継承がある．関連は複数のクラス同士が，互いに役割をもって実現する関係である．例えば，救急車という役割をもつ自動車は病院という役割をもつ建物と関連するであろう． クラスB ：0または1 関連表示の例 0,1 クラスB ：1以上 1..* クラスA クラスB 役割A 役割B （* は複数を表す。n と記述することもある） 「,(カンマ)」で区切ることで離散値を指定し，「..(2つのドット)」で区切ることで範囲を指定する。 1,2 1..*

関連の向き 関連は「向き」を持つことができる。 例 ：「道路」から「交差点」への片方向の関連 クラスA クラスB 道路 交差点 例　：「道路」から「交差点」への片方向の関連 クラスA クラスB 役割B 1..* この場合、道路は，どの交差点で区切られるかを知ることができるが，交差点は，どの道路を区切るかわからない。 道路 端点 交差点 0..2

特殊な関連 集成（aggregation） 全体と部分の関連性 「has a」または「is a part of」の関係 記法：全体を表すクラスの側に「白抜きダイヤモンド」をつける 合成（composition） 強い集成，部分と全体が一体となる関連 記法：全体を表すクラスの側に「黒いダイヤモンド」をつける 全体クラス 役割名 部分クラス 役割名 全体クラス 部分クラス 集成は，集約としているテキストもあるが，JIS規格の呼称に従って，ここでは集成としている．合成では，全体を示すクラスのインスタンスが消滅した時，部品となるインスタンス群も消滅する．集成の場合は，それはない． 1 0..* 全体クラス 役割名 部分クラス 役割名 全体クラス 部分クラス 1 2

特殊な関連の例 ジュースの容器 キャップ ラベル ペットボトル 駅 改札口 プラットホーム 集成 合成 駅のインスタンスが消滅するということは，改札口やプラットフォームもなくなるということ． 改札口 プラットホーム

継承 継承 (inheritance)とは より抽象的な型と下位の具体的な型の関係 上位の属性、操作、及び関連を下位が受け継ぐ is aの関係ともいう。 継承の描き方 上位クラスと下位クラスを線で結び、上位クラス側に「白い三角」を付ける クラスA 岩石 硬度 成分 属性A 例えば，火成岩は岩石であり，硬度，成分，そして固化速度を属性とする． 操作A 特化 汎化 クラスBが持つ属性 　属性A（クラスAから継承） 　属性B クラスBが持つ操作 　操作A（クラスAから継承） 　操作B クラスB 属性B 操作B 火成岩 固化速度 堆積岩 堆積地

多重継承 多重継承：複数の上位クラスからの継承 クラスA クラスC 属性A 属性C 操作A 操作C 建物 名前 位置 鉄道施設 会社名 属性A 属性C 操作A 操作C 「クラスB」は「クラスA」であり，かつ「クラスC」でもある。 駅 管理者 クラスB 属性B 多重継承は，クラス図を複雑にし，その信頼性を損なう可能性があるため，極力使用すべきではない．事実，Javaのように多重継承を禁止しているプログラム言語もある． 操作B 「駅」は「建物」でもあり，「鉄道施設」でもあるため，両者を継承する。 その結果，「駅」は以下の属性を持つ。 名前 位置 会社名 管理者 建物から継承 鉄道施設から継承 駅に定義

抽象、具象、ルート 具象クラス インスタンス化されるクラス ルート 抽象クラス 抽象的な概念を示すクラス 下位の具象クラスがインスタンスを作れる クラス名を斜体にして記述する ルートクラス クラス図の中で，継承の最上位となるクラス ルート 道路 名前 種類 国道 県道 交通量 点字ブロック有無 ルートクラスは，最上位に来るクラスという意味でしかなく，抽象でも具象でもよい． 具象クラス： 　車道，歩道 抽象クラス： 　道路 抽象クラスである道路は直接インスタンス化されず，道路を継承する車道及び歩道がインスタンス化される。

多態性 (Polymorphism) 多態性:上位の具象クラスのインスタンスが、下位のクラスのインスタンスである場合、下位のクラスの操作が実行されること。 多態性の例 日当り？ 静か？ 収納？ 部屋数？ セキュリティ？ 住宅 住みよいか（） 多態性は，多相性とも呼ばれる．多態性を示す下位の操作は，上位の操作をoverloadすると言われる． 集合住宅 住みよいか（） 個人住宅 住みよいか（） 住宅の評価項目 コミュニティ？ プライバシー？ 住宅の評価項目 周辺の環境？ 庭？

<<DataType>> データ型 地物型の属性の型として使われる，地物ではないクラスをデータ型（DataType）という。 例えば，地物の座標を示す「位置」は，地物の属性の型としてしか，使われない。 <<DataType>> 位置 緯度：Long 経度：Long 緯度：35.5421は 35度32分31.56秒

文書化 フリーなツールの例： Argo UML astah* Community クラス図の要素（クラス、属性、操作、関係）の定義は文章で示す。 建物：屋根と壁で区切られた人工構造物 名前：他の建物と区別するために与える識別情報。 種類：建物の特徴を示す名前 建物 名前 種類 クラス図は通常、専用のソフトウェアツールで作成する。ツールは必ずクラス図の要素の定義を記入できるようにしている。 フリーなツールの例： Argo UML astah* Community

その他のスキーマ言語 ー 実体関連モデル 実体関連モデル(Entity-Relationship Model): 1976年にP.Chenによって提唱された、グラフィックなスキーマ言語。 他と区別できる“もの”を実体とし、その間の関連とともに、実体関連図として表現。 実体は長方形で表現し、属性をもつことができる。 関連は菱形で表現し、属性をもつことができ、実体同士の多対多の関連を表現できる。 教授 学生 教師 受講 科目 ー名前 ー学籍番号 ー住所 ー点数 ー科目名 ー必修・選択 N 1 M この実体関連図では、一人の教師が、複数の学生を教授し、複数の科目と、複数の学生が受講で関連することが示されている。学生は学籍番号、名前及び住所という属性をもち、教師は名前、科目は科目名必修・選択の別を属性とする。また、受講という関連は、科目毎に学生に与えられる点数を属性としている。

まとめ モデルの記述が自然言語だと、表現にあいまいさが残る スキーマ言語を使って、モデルの形式表現を行うことで、あいまいさを軽減する スキーマ言語の一つとしてUMLがある。 UMLでは、同じ性質をもつものの集まりをクラスとし、属性、操作、他のクラスとの継承及び関連でスキーマを表現する。 クラス図の要素の定義は、文章で補う。 UMLのようなスキーマ言語は突然現れたものではなく、それ以前から例えば実体関連モデルのようなスキーマ言語がある。

参考文献 有川正俊、太田守重監修（2007）『GISのためのモデリング入門』ソフトバンククリエイティブ Michael Worboys and Matt Duckham (2004) GIS: a computing perspective, Second Edition, CRC Press, pp.71-80 Peter Pin-Shan Chen, The Entity-Relationship Model-Toward a Unified View of Data, ACM Transactions on Database Systems, Vol. 1, No. 1. March 1976, Pages 9-36.