UMLによる概念モデリング入門.pdf

UMLクラス図概念モデリング入門 2020年03月某日株式会社メソドロジック矢崎博英

所属株式会社メソドロジック取締役／CTO 専門開発方法論、データモデリング、オブジェクトモデリングのコンサルティング経歴主に基幹システムの再構築プロジェクトにモデラーとして参画某都道府県警の通信指令システム（いわゆる１１０番）テレビ局営報システム（番組編成・CM・放送これDDDでやりました！）
化学工業の生産管理鉄鋼メーカー合併によるシステム統合 etc. 訳書 Writing Effective Use Cases（著者Alistair Cockburn）翻訳（2001年） Microservices IN ACTION（著者Morgan Bruce, Paulo A. Pereira ）2020年夏頃出版予定雑誌連載 JavaWorld ゼロから始めるオブジェクト指向（2001年～2002年11月）日経オープンシステムズ UML／J2EEによるシステム構築の実際（2002年10月~2003年3月）自己紹介矢崎博英 1

UMLクラス図を使った概念モデリングの初歩を学ぶ • 概念モデルとは何か • 概念モデリングの効果 • UMLクラス図の表記法。特に概念モデルを描くときに使われる要素について • 概念モデリングで前提となる数学の考え
• 実践で使えるアプローチ 2 本日の講義内容

3 はじめに

Unified Modeling Languageの略称 • 統一されたモデリング言語 • OMG（Object Management Group）が管理 ※OMGは国際的なオープンかつ非営利の技術標準化コンソー
シアムである • 1980年代後半から1990年代前半にかけてオブジェクト指向のモデリング言語が数多く台頭したことに対し、それらを統一する中で生まれた • 最新バージョンは2.5.1（2020年1月25日現在） 4 UMLとは

UML2.５.1では7種類の構造図と7種類の振る舞い図が用意されている 5 UML構造図および振る舞い図のタクソノミーダイアグラム構造図プロファイル図クラス図コンポジット構造図オブジェクト図
コンポーネント図配置図パッケージ図振る舞い図アクティビティ図相互作用図ユースケース図状態マシン図シーケンス図コミュニケーション図相互作用概要図タイミング図クラス図 UMLではクラス図を使って概念モデルが表現される

6 UMLクラス図による概念モデル例 - 注文番号 : 注文番号 {unique} - / 販売額合計
: Money - 注文年月日 : 営業日注文 - （注文×商品） {unique} - / 販売額 - 値引額 - 注文個数注文明細 - 住所 : 住所 - 個客名 : String - 個客コード : 個客コード {unique} 顧客 - 注文 - 注文者 0..* 1 法人顧客個人顧客 {disjoint, complete} - 個数 : 正の整数セット商品組合せ国内顧客国外顧客 - 単価 : Money - 商品名 : String - 商品コード : 商品コード {unique} 商品 - 注文品 0..* 1 - 入社年月日 : 営業日 - 生年月日 : Date - 社員名 : String - 社員番号 : 正の整数 {unique} 社員 - 受注担当者 1 0..* - 担当先 - 担当者 0..* 1..* - 担当期間 : 期間担当 - 営業履歴番号 : 営業履歴番号 {unique} - メモ : String[0..3] - 年月日 : Date 営業活動 0..* 1 受注担当社員顧客担当社員 {disjoint, incomplete} 提案挨拶相談対応法人顧客注文個人個客注文 {disjoint, complete} 1 0..* {redefines 注文者} {redefines 注文} 1 0..* {redefines 注文者} {redefines 注文} - 商品カテゴリ名 : String - 商品カテゴリコード : String {unique} 商品カテゴリ - 商品カテゴリ 0..* 1..* - 主商品カテゴリ 0..* 1 {subsets 商品カテゴリ} {階層構造} - セット商品 - 構成商品 0..* 0..1 {ordered} 1..5 {disjoint ,imcomplete} 法人個客担当者 0..* 1 - 営業相手 0..* 1..* - （商品×倉庫） {unique} - 在庫数商品在庫 1 0..1 倉庫 0..1 1 一般顧客重要顧客 <<動的>> {disjoint, complete} - 部署名 : String - 部署コード : 部署コード {unique} 部署 - 所属部署 0..* 1 - 売上目標額 : Money - 年月 : 年月売上目標年月 0..1

7 UMLクラス図による概念モデル例 - 注文番号 : 注文番号 {unique} - / 販売額合計
: Money - 注文年月日 : 営業日注文 - （注文×商品） {unique} - / 販売額 - 値引額 - 注文個数注文明細 - 住所 : 住所 - 個客名 : String - 個客コード : 個客コード {unique} 顧客 - 注文 - 注文者 0..* 1 法人顧客個人顧客 {disjoint, complete} - 個数 : 正の整数セット商品組合せ国内顧客国外顧客 - 単価 : Money - 商品名 : String - 商品コード : 商品コード {unique} 商品 - 注文品 0..* 1 - 入社年月日 : 営業日 - 生年月日 : Date - 社員名 : String - 社員番号 : 正の整数 {unique} 社員 - 受注担当者 1 0..* - 担当先 - 担当者 0..* 1..* - 担当期間 : 期間担当 - 営業履歴番号 : 営業履歴番号 {unique} - メモ : String[0..3] - 年月日 : Date 営業活動 0..* 1 受注担当社員顧客担当社員 {disjoint, incomplete} 提案挨拶相談対応法人顧客注文個人個客注文 {disjoint, complete} 1 0..* {redefines 注文者} {redefines 注文} 1 0..* {redefines 注文者} {redefines 注文} - 商品カテゴリ名 : String - 商品カテゴリコード : String {unique} 商品カテゴリ - 商品カテゴリ 0..* 1..* - 主商品カテゴリ 0..* 1 {subsets 商品カテゴリ} {階層構造} - セット商品 - 構成商品 0..* 0..1 {ordered} 1..5 {disjoint ,imcomplete} 法人個客担当者 0..* 1 - 営業相手 0..* 1..* - （商品×倉庫） {unique} - 在庫数商品在庫 1 0..1 倉庫 0..1 1 一般顧客重要顧客 <<動的>> {disjoint, complete} - 部署名 : String - 部署コード : 部署コード {unique} 部署 - 所属部署 0..* 1 - 売上目標額 : Money - 年月 : 年月売上目標年月 0..1 クラス関連多重度関連単名汎化コンポジション制約限定子クラス名属性再帰関連属性の型関連クラス

言葉のとおり、概念のモデルすなわち、ある目的をもって問題領域を分析あるいは可視化するために、その問題領域に関わる人々が抱く概念群を再構成した上で形式的手法で表現すること 8 概念モデル（Conceptual Model）とは

内包概念の内容。事物の本質的な特徴とそれらの連関外延概念が適用される一定範囲の事物（事物の集まり）事物物と事（出来事やアイディア、約束事など） 9 概念概念〘哲〙
①事物の本質をとらえる思考の形式。事物の本質的な特徴とそれらの連関が概念の内容（内包）をなし、同一の本質をもつ一定範囲の事物（外延）に適用されることで一般性をもつ。例えば、人という概念の内包は人の人としての本質的特徴（理性的動物あるいは社会的動物など）であり、外延はその特徴をもつあらゆる人々である。・・・（略）・・・概念は言語に表現されて「名辞」と呼ばれ、その意味内容として存在する。・・・（略）・・・ ②大まかで一般的な意味内容。岩波書店広辞苑第七版

概念のモデルとしての品質／有効性必要なことをできるだけ表現できること（表現力）多義的やあいまいさなく意味を伝えられること（形式性）形式性を確保するために、数学の力を借りよう特に集合論 • 実は、古いオブジェクト指向の書籍の中には、クラスやオブジェクトを集合を使って説明しているものが多かった •
私と同年代の方や少し先輩の方の著作も同様のものが多い 10 哲学的に定義された概念を形式的に扱うために

11 集合論でオブジェクト指向を説明している著書例

12 補足：集合論によらないオブジェクト指向の考え

13 概念

集合集合とは、いくつかのものをひとまとめにして考えた’ものの集まり’ 数学的には“どんなものをとってきても、それがその集まりの中にあるかないかがはっきりと定まっている“ようなものでなければならない集合の記法（個々の集合を具体的に表す記法） • 外延的記法：集合の要素を列挙して集合を表す例）｛1, 2, 3,
4, 5, 6, 7, 8, 9｝ • 内包的記法：条件Pを示して集合を表す｛x | P(x)} 例）｛x | 0 < x < 10, x ∈ ℤ} 集合の例 • 自然数全体の集合（ℕ）、整数全体の集合（ℤ）、有理数全体の集合（ℚ）、実数全体の集合（ℝ）、複素数全体の集合（ℂ） • 当社社員全員からなる集合 14 集合

元（または要素） • 集合に含まれるものを元（または要素）という • aが、集合Aの元であることを、記号で a ∈ A と書く（元でないときは
a ∉ A） • 集合A、Bがまったく同じ元からなるとき、かつ、そのときに限りA とBは等しい（A ＝ B） • ｛1, 2, 3｝ = {3, 2, 1}, {1, 2, 3} = {1, 2, 2, 3} • 集合と元はベン図で表すことができる 15 集合円は集合を表す円の中にある点（や他の図形は、この集合の元である（a ∈ A） a A ← 集合の名前円の外にある点（や他の図形）は、この集合の元でない（b ∉ A） b 顧客田原さん近藤さん松田さん野村さん中森工業小泉百貨店河合自動車野口さん山口さんパソコンX

16 概念モデルの第一歩→概念・集合をクラスで表す顧客田原さん近藤さん松田さん野村さん中森工業小泉百貨店河合自動車
属性区画、操作区画は省略可能顧客顧客顧客クラスクラス名属性区画操作区画

有限／無限集合集合には元の数が有限個の有限集合と無限個の無限集合がある単集合１つの要素しか含まない集合を単集合という｛x | 0 < x <
2, x ∈ ℤ} = {1} ※ {1} ≠ 1 空集合要素を１つも含まない集合を空集合という｛x | 0 < x < 1, x ∈ ℤ} = {} = ∅ 有限集合／無限集合、単集合、空集合単集合の例：当社本社空集合の例：2乗して負数になる実数今、たまたま空集合である場合（別の時点では非∅）と、いついかなるときでも空集合になるものがある当社本社 2乗して負数になる実数

18 ドメインと概念顧客輸送車両商品受注社員物流拠点自社 XXX株式会社の業務ドメイン
ドメインのスコープを表す枠＝全体集合ドメインの中にはたくさんの要素があるそれらの要素を、概念が適用される集合へと分類する

19 ドメインと概念顧客輸送車両商品受注社員物流拠点自社 XXX株式会社の業務ドメイン
顧客輸送車両受注商品社員物流拠点自社ドメインのスコープを表す枠＝全体集合ドメインの中にはたくさんの要素があるそれらの要素を、概念が適用される集合へと分類する集合・概念をクラスで表現する

以下の業務ドメインのいずれかを対象として、情報システム化することを目的に概念を抽出しましょう • Scrumのプロジェクト管理 • 野球の試合管理業務（試合の勝敗や選手の成績等） • マイ・ツィッター • 会社の図書管理業務
20 演習：概念の抽出

21 属性

概念を説明するためのデータ項目を属性という属性の例顧客顧客番号、顧客名、配送先住所、請求先住所、メールアドレス、生年月日、性別、好きなジャンル、・・・商品商品番号、商品名、価格、販売開始年月日、評価最高点、評価最低点、メーカー名、販売店、・・・注文注文番号、注文年月日、注文者番号、注文商品番号、使用クーポン番号、配送オプション区分、
配送先住所、・・・概念が適用される個体（要素）それぞれが自分自身の属性値を持つ（属性値がないという場合もある）リレーショナルモデルの第3正規形（あるいは、より高度の正規形）にするのは基本だが必須ではない 22 属性

- お知らせメールを希望する : boolean = true - 顧客コード : 顧客コード
- メールアドレス[1 .. 5] : メールアドレス - 生年月日 : 年月日 - 氏名 : 文字列顧客属性はUMLではクラスの属性区画に以下の形式で記述される 23 UMLでの属性の表現方法属性名属性の型可視性属性名:属性の型 [多重度] = 初期値可視性多重度初期値 • 多重度は以下の形式で表す [多重度の最小値 .. 最大値] または、取りうる値の数列（カンマ区切り） • 最大値が無い（いくらでもよい）場合はアスタリスク（*）で表す。 • 例） • [0..*] 0以上 • [*] 0以上 • [1..*] 1以上 • [5..10] 5以上10以下 • [1, 3, 5] 1または3または5（0や2や4や6以上はだめ） • [1] 丁度1 属性 23

属性の型はプログラム言語の組み込みの型ではなく、値として取りうる範囲が示せる型を定める例）属性「注文数」の型 × Integer（整数）〇自然数（または正の整数）これにより概念の性質がよりはっきりしてくる以下を考えてみよう •
数値や数字であれば、最小値、最大値が無いか • 数値や数字であれば、値の刻みが無いか • 文字列であれば桁数の最小値、最大値が無いか • 文字列であれば使用できる文字が限定されていないか • なんらかの形式を持たないか（商品番号、メールアドレス・・・） 24 属性の型

属性の中にはその値が他の属性の値から計算されるものがある。このような属性を派生属性という属性名の前に／をつけて、その属性が派生属性であることを表す左図の派生属性 – 社員#年齢社員#生年月日と現在年月日から計算 –
注文#販売金額合計紐づく注文明細の注文金額を集計 – 注文明細#注文金額紐づく商品の単価×注文明細#注文数条件によって派生になったり入力値になったりすることがある。そのような場合のモデルの表現は確立されていない 25 派生属性 - / 販売金額合計 - 注文年月日 - 注文番号注文 - 注文品 0..* 1 - 注文明細 1..* 1 - / 注文金額 - 注文数 - 明細番号注文明細 - / 年齢 - 生年月日 - 住所 - 氏名 - 社員番号社員 - 受注担当社員 0..* 1 - 単価 : 日本円 - 商品番号 : 商品番号商品

属性値をとらないのはどのような場合か • その要素は本来その属性に値をもたない • 汎化／特化を検討する（後述） • 今のところその属性の値を持っていない（いつかは持つかも） • 属性値が不明（その属性の値を持っているか否かがわからない。持っていたとしても値が不明）
• 履歴データで、前の値から変わっていない（特殊）本当はこれらを区別した値がもたれるべきだが、いずれもnull値がセットされることが多い 26 属性値をとらない可能性

属性の識別や詳細化を徐々に行っていく • 可視性は概念モデルでは基本的に不要 • 多重度はマルチバリューのときのみ • 初期値も必要なときのみで 27 属性の識別や詳細化顧客
お知らせメールを希望するメールアドレス[1 .. 5] 生年月日氏名顧客コード顧客お知らせメールを希望する : boolean メールアドレス[1 .. 5] : メールアドレス生年月日 : 年月日氏名 : 文字列顧客コード : 顧客コード顧客お知らせメールを希望する : boolean = true 顧客コード : 顧客コードメールアドレス[1 .. 5] : メールアドレス生年月日 : 年月日氏名 : 文字列顧客概念を識別属性を識別属性の型を決める初期値を決める属性の初期値を決める

先の演習で抽出した以下の業務ドメインの概念に属性を追加しましょう。必要なら概念の見直しもしましょう • Scrumのプロジェクト管理 • 野球の試合管理業務（試合の勝敗や選手の成績等） • マイ・ツィッター •
会社の図書管理業務 28 演習：概念の属性の抽出

29 関連

概念モデルでは、概念が適用される個体（集合の要素）どうしの結びつきもモデル化する 30 関連集合の要素どうしの結びつき

31 集合の要素どうしのいろいろな結びつき 1対1 1対多多対1 多対多再帰合成

結びつきを持つ要素、もたない要素が混在する場合がある 32 結びつきをもたない要素結びつきを持たない結びつきを持たない結びつきを持たない
結びつきを持たない

• 全体と部品 • １つの要素をいくつかの部分に分けたときの全体要素と部分要素の関係 • 先行する要素と後続する要素 • 袋（入れ物）と中身
• 同じ種類の要素どうしの対等な関係 • ヘッダと明細 • 要素とその現在位置 • 要素とその履歴 • 要素とその所属先 • 要素とその住まい（住居・倉庫・設置場所や住所） • 要素と生誕地 • 要素とそれが一時的に乗っているもの • 要素とその役割 • 要素とその状態 • 要素とそれを説明する他の要素など 33 結びつきのタイプ

部署 - 単価 : 日本円 - 商品番号 : 商品番号商品
- / 販売金額合計 : 10万未満の正整数 - 注文年月日 : 当社営業日 - 注文番号 : 注文番号注文 - / 注文金額 : 10万未満の正整数 - 注文数 : 正整数 - 明細番号 : 正整数注文明細 - 注文品 0..* 1 - 注文明細 1..* 1 社員 - 受注担当 0..* 1 - 部員 - 所属部署 0..* 1 - お知らせメールを希望する : boolean = true - メールアドレス[1 .. 5] : メールアドレス - 生年月日 : 年月日 - 氏名 : 文字列 - 顧客コード : 顧客コード顧客 - 注文主 0..* 1 注文する {階層} - 子商品 - 親商品 0..* 0..1 関連はクラスとクラスの間に実線を引いて表す関連には以下の情報を定義できる • 関連名 • 多重度 • 関連端 • 誘導可能性 • 制約 • 限定子（後述） • 集約／コンポジション（後述）要素どうしの個々の結びつきを、関連のインスタンス、あるいはリンクという 34 UMLでの関連の表現方法関連多重度関連端関連名誘導可能性再帰関連制約集合の要素どうしの結びつきをUMLでは関連で表現する

関連名関連につけられた名称。▶の指し先が関連の目的語になる関連端名関連の相手に付けられた名称。後述の「対応」に対応する多重度関連の相手としていくつの要素が対応するかを示す。属性と同じく、多重度の最小値 ..
最大値、または、取りうる値の数列（カンマ区切り）で表し、最大値が無い（いくらでもよい）場合はアスタリスク（*）で表す。 • 0..* 0以上 • * 0以上 • 1..* 1以上 • 5..10 5以上10以下 • 1, 3, 5 1または3または5 • 1 丁度1 35 関連名・関連端名・多重度 - 単価 : 日本円 - 商品番号 : 商品番号商品 - / 販売金額合計 : 10万未満の正整数 - 注文年月日 : 当社営業日 - 注文番号 : 注文番号注文 - / 注文金額 : 10万未満の正整数 - 注文数 : 正整数 - 明細番号 : 正整数注文明細 - 注文明細 1..* 1 - 注文品 0..* 1 - お知らせメールを希望する : boolean = true - メールアドレス[1 .. 5] : メールアドレス - 生年月日 : 年月日 - 氏名 : 文字列 - 顧客コード : 顧客コード顧客 - 注文主 0..* 1 注文する - 子商品 - 親商品 0..* 0..1 {階層} 多重度関連端関連名

36 多重度の書き方 1対1 1対多 1対多（結びつきを持たない要素有）社員社員顧客顧客社員
顧客 1 1 社員顧客 *だけでもよい 0..1 0..* 社員顧客 1 1..* 社員顧客 0..* 0以上 * 0以上 1..* 1以上 5..10 5以上10以下 1, 3, 5 1または3または5 1 丁度1

37 多重度の書き方多対多（結びつきを持たない要素有）多対多 0..* 0..* 社員顧客 1..* 1..*
社員顧客社員顧客社員顧客 0..* 0以上 * 0以上 1..* 1以上 5..10 5以上10以下 1, 3, 5 1または3または5 1 丁度1 *だけでもよい

たまたまある時点では、ある多重度（例えば1:多）になる場合があるとしても、別の時点で他の多重度（例えば多対多）になる可能性がある場合は、より数の範囲が広い方の多重度を付記すること 38 多重度の注意点

39 誘導可能性・制約・再帰関連誘導可能性関連の一方からもう一方を参照できるかどうかを示す制約関連に制約や追加の意味を付与する。制約を表すキーワードをブレイス（{ }）で括って表す例）{階層}, {ordered}
再帰関連同一概念の要素間に関連があることを示す例） • セット商品はいくつかの単商品から構成される • グラフ理論：頂点は辺でつながる線の先が矢印矢印の反対側から矢印側を参照できる線の先が× ×の反対側から×側を参照できない線の先が無印誘導可能性は未定 - 単価 : 日本円 - 商品番号 : 商品番号商品 - / 販売金額合計 : 10万未満の正整数 - 注文年月日 : 当社営業日 - 注文番号 : 注文番号注文 - / 注文金額 : 10万未満の正整数 - 注文数 : 正整数 - 明細番号 : 正整数注文明細 - 注文明細 1..* 1 - 注文品 0..* 1 - お知らせメールを希望する : boolean = true - メールアドレス[1 .. 5] : メールアドレス - 生年月日 : 年月日 - 氏名 : 文字列 - 顧客コード : 顧客コード顧客 - 注文主 0..* 1 注文する - 子商品 - 親商品 0..* 0..1 {階層} 誘導可能性制約再帰関連

同一集合の要素の間にリンクがある場合、その関連を再帰関連という 40 再帰関連駅 - 住所 - 駅名 -
駅番号駅 - 前駅 - 次駅 0..* 0..* 再帰関連は該当するクラスから出て戻る関連で表す再帰関連の例駅と次駅セット商品と構成商品組織構造

再帰関連には以下のような形態がある階層構造（木構造）（親が高々１つ）ネットワーク構造（親が0以上） 41 再帰関連：階層構造とネットワーク構造部1 : 組織課1a :
組織課1b : 組織係1aあ : 組織係1aい : 組織係1aう : 組織係1bえ : 組織係1bお : 組織部2 : 組織課2a : 組織課2b : 組織係2aあ : 組織係2aい : 組織係2bう : 組織係2bえ : 組織課2c : 組織階層構造の例：組織構造ネットワーク構造の例：路線赤羽 : 駅池袋 : 駅新宿 : 駅代々木 : 駅原宿 : 駅渋谷 : 駅新大久保 : 駅目白 : 駅高田馬場 : 駅大塚 : 駅木構造の場合ノードの数 = エッジの数-1

セミナー申込人法人 - 申込者 1 0..* - 申込者 1
0..* あるクラスから２つ以上の関連があり、同時にはそのうちの１つのリンクしか持てない場合{xor}という制約を付記するとよい 42 XOR {xor} セミナーの申込者は、法人あるいは人のいずれかで、同時に法人と人が申込者であることはあり得ないこの多重度は、相手のリンクがないときの多重度をつけるのがよいと考える

概念モデルでは属性と関連は同じものの表現の違いにすぎない 43 属性は関連でもある - 基本給 : 日本円 - Eメールアドレス :
Eメールアドレス - 住所 : Address - 氏名 : String - 社員番号 : 社員番号社員社員社員番号 - 社員番号 1 0..1 氏名 - 氏名 0..* 1 住所 - 住所 0..* 1 Eメールアドレス - Eメールアドレス 1 0..1 Money - 基本給 1 0..* 社員番号は共有されないので多重度は高々1 同姓同名がいるかもしれかもしれないので多重度は 0以上属性名は関連端名となる属性型名はクラス名となる

型がエンティティの場合は、関連で表現型がエンティティでない場合は、属性で表現ただし多重度が[0..1], 1以外は関連で表現するエンティティでないものも別途どこかでモデルとして列挙する形で描いておくとよい 44 属性と関連での表現の使い分け - 連絡先メールアドレス
: メールアドレス文字列[1..5] - 氏名 : String - 会員番号 : 会員会員 - 連絡先メールアドレス 1..5 1 - メールアドレス : メールアドレス文字列メールアドレス - 氏名 : String - 会員番号 : 会員会員 0..* 1 - 部署名 : String - 部署ID : 部署ID 　部署　 - 氏名 : String - 社員番号 : 社員番号　社員　

以下の業務ドメインのいずれかを対象として、情報システム化することを目的に概念、概念の属性、概念間の関連を抽出しましょう • Scrumのプロジェクト管理 • 野球の試合管理業務（試合の勝敗や選手の成績等） • マイ・ツィッター •
会社の図書管理業務 45 演習：関連の抽出

以下の概念をクラスで表し、概念間の関係を関連で表現してください。属性、多重度、関連端名もできるだけ書きましょうドメインは会議室予約とします概念 • 会議室 • 会議室に設置されている備品 •
予約（予約者（社員）1名がおり、また会議参加者（社員）を複数名登録できる） • 社員 46 演習：概念モデルを描いてみよう

47 回答例 - 場所 - 収容人数 - 会議室名 - 会議室ID
会議室 - 備品ID 備品 - 予約取り消し区分 - 予約年月日 - 会議室予約番号会議室予約 - 予約対象会議室 0..* 1 - 設置備品 - 設置先会議室 0..* 0..1 - 氏名 - 社員番号社員 - 予約者 0..* 1 - 出席者 0..* 0..* - 名称 - 備品区分コード備品区分 0..* 1 この多重度は・予約者以外の出席者を示す関連だとすれば最小値0（予約者が1人で会議室を使う場合もある）・そうでなくて予約者も含んだ出席者を示すとすれば最小値は1 ・もっと言えば、予約者が出席するとは限らない（予約だけする人）ので、そう考えたら最小値は1にすべき・でも、ちょっと待てよ。先に会議室だけとって、あとから参加者を決める、というのもあるか。そういう意味では参加者の設定はしてもしなくてもよい、とすべきか・・・

制約とは、UMLの記号に追加の意味を表現するための記号 • 制約はブレイス{ }で囲んで表示する例）{ordered}, {階層} • 1つの関連に複数の制約を指定したい場合は、ブレイス内にカンマで区切って並記する
例）{制約1, 制約2} • 制約は関連だけでなくいろいろなものに付けることができる 48 制約

{階層}は、組織の上位・下位の関係がツリー構造になっていることを表す 49 関連の代表的な制約 {階層} 組織 {階層} - 下位組織 -
上位組織 0..* 0..1 制約階層部1 : 組織課1a : 組織課1b : 組織係1aあ : 組織係1aい : 組織係1aう : 組織係1bえ : 組織係1bお : 組織部2 : 組織課2a : 組織課2b : 組織係2aあ : 組織係2aい : 組織係2bう : 組織係2bえ : 組織課2c : 組織こちらの多重度は必ず0..1 ※無限を考えない場合こちらの多重度の最小値は必ず0 無限を考えない場合

50 {階層}では以下は許されない部1 : 組織課1a : 組織課1b :
組織係1aあ : 組織係1aい : 組織係1aう : 組織係1bえ : 組織係1bお : 組織部2 : 組織課2a : 組織課2b : 組織係2aあ : 組織係2aい : 組織係2bう : 組織係2bえ : 組織課2c : 組織このリンクは許されないツリー構造ではない下位組織上位組織

{階層}はツリー構造であることを指定しているだけ左記のような構造も許されるこれを許さないためには別の方法が必要 51 {階層} これは許される
部1 : 組織課1a : 組織課1b : 組織係1aあ : 組織係1aい : 組織係1aう : 組織係1bえ : 組織係1bお : 組織部2 : 組織課2a : 組織課2b : 組織係2aあ : 組織係2aい : 組織係2bう : 組織係2bえ : 組織課2c : 組織部1 : 組織課1a : 組織課1b : 組織係1aあ : 組織係1aい : 組織係1aう : 組織係1bえ : 組織係1bお : 組織部2 : 組織課2a : 組織課2b : 組織係2aあ : 組織係2aい : 組織係2bう : 組織係2bえ : 組織課2c : 組織部の下に課をはさまずに係た直接ついている係の下に課がつく

リンクしている要素に順序がある。つまりリスト（いったんそう考えるが、そうならない場合も。後ほど再考）例）渋41[東急バス]の路線 [渋谷駅, 道玄坂上, 大坂上, 大橋, 菅刈小校, ・・・] 52
関連の代表的な制約{ordered} 制約 ordered バス路線停留所 {ordered} - 停留所 1..* 1..* 路線停留所 ① ② ③ ④ ① ② ③

親が複数の場合があり、その場合は親毎に並びがある同じ停留所でも路線によって順番が変わるリスト内に同一のものが2回以上でてくるか否か同一のものがリスト内に2回以上登場しない、という場合は制約uniqueを使う {ordered,
unique} 関連の代表的な制約{ordered} 路線停留所 ① ② ③ ④ ① ② ④ ③ 路線X 路線Y 路線停留所路線X ① ② ③ ④ ⑤ ⑥ ⑦

以下はリストにならないケース同一順序がある、というのを許すか半順序（順序づけできないものどうしがある）を許すか 54 関連の代表的な制約{ordered}

同じ概念間に複数の異なる意味の関連がある場合、その分だけの関連線を引かなければならないそれらは異なる関連である多重度が異なる場合がある誘導可能性のある向きの関連端名はかならず異なる。区別するためできるだけ名前をつける例） • 注文品以外に試供品を頼むことができる注文（試供品は頼まなくてもよい） • 旅行の出発駅、到着駅、解散駅
同じ概念間の複数の関連受注商品注文品としてのリンク試供品としてのリンク 55 - 注文品 1 0..* - 試供品 0..1 0..* 商品受注 - 到着駅 1 0..* - 解散駅 1 0..* - 出発駅 0..* 1 駅旅行

次に関連クラスおよび限定子を説明しますその前提知識としてまず直積と関係について少し学んでいただきます 56 関連クラスと限定子

集合Ａの任意の元aと集合Bの任意の元bとの順序づけられた組(a, b)の全体からなる集合をＡとＢとの直積といいＡ×Ｂと書くＡ×Ｂ={(a, b)| a ∈Ａ, b ∈
Ｂ} 直積直積 1 2 a b c (1,a) (1,b) (1,c) (2,a) (2,b) (2,c) A B • 直積は、集合Aの全要素、集合Bの全要素の順序づけられた組み合わせ • 集合AとAの直積もある。このときA×AやA2と書く • 3以上（無限でもよい）の集合の直積も考えられる。このとき、A×B×C、A3 等と書く「任意の」とは集合の要素としてどれでもよいから勝手にとって、という意味。勝手に何をとっても条件が成立する、ということになるので、集合の全ての要素が持つ条件を述べるときに「集合Aの任意の要素aに対して条件Pが成り立つ」というような言い方をする

集合A、B、C、Dが以下のとおり与えられたとき、以下の各問に答えよ 1. 直積A×Bを外延的記法で表せ 2. 直積B×Aを外延的記法で表せ 3. 直積A×B×Cを外延的記法で表せ 4. 直積A×Aを外延的記法で表せ
5. 直積A×Dを外延的記法で表せ 58 演習：直積 A={1, 2, 3}, B={x, y}, C={〇, □}, D=∅

1. {(1, x), (1, y), (2, x), (2, y), (3,
x), (3, y)} 2. {(x, 1), (x, 2), (x, 3), (y, 1), (y, 2), (y, 3)} 3. {(1, x, 〇), (1, x, □), (1, y, 〇), (1, y, □), (2, x, 〇), (2, x, □), (2, y, 〇), (2, y, □), (3, x, 〇), (3, x, □), (3, y, 〇), (3, y, □)} 4. {(1, 1), (1, 2), (1, 3), (2, 1), (2, 2), (2, 3), (3, 1), (3, 2), (3, 3)} 5. {} ※任意の集合Aに対してA ✖ ∅ = ∅ ✖ A = ∅ 59 演習:直積答え

概念Xと概念Y（YはXであってもよい）の間の関連は、集合論におけるXとYの2 項関係（あるいは単に関係）とみなすことができる 2項の間の関係Rは、数学では通常次のように書く R(x, y) （x ∈ X, y ∈
Y） ※x, yは変数である ※xRyという書き方もある上のRは、xとyにそれぞれXとYに属する要素を代入したときに真偽が決まる条件である。関連を関係とみるときには、xとyに代入された対象の間にリンク（関連のインスタンス）が存在するとき、かつそのときに限り真となる、条件とするすると、R(x, y)が真となる組(x, y)の全体は、A×B（AとBの直積）の部分集合を形づくる。この集合を関係Rのグラフといい、G(R) で表す。すなわち G(R) = {(x, y) | x ∈ X, y ∈ Y, R(x, y)} 同様にして2項を越える関係（3項、4項・・・）や、そのグラフを定義する 60 関係（集合論での）

• 関連が属性や、他への関連を持つ場合がある • それを示すには、関連をクラスとして表現し、属性をもたせたり、他クラスへの関連線を引く • 関連をクラスとして表現したものを関連クラスという • 「社員」と「組織」の間の関連「所属」には、配属年月日という属性を持つ •
「エンジニア」と「プロジェクト」の間の関連「参画」は、「ロール」という概念への関連を持つ ※関連クラスは前スライドで説明した関係のグラフとみなすことができる 61 関連クラス参画 1..* 0..* ロール 0..* 0..* プロジェクトエンジニア 1 0..* - 配属年月日所属組織社員関連クラス関連クラスは、関連線から点線でつながるクラスで表す関連クラスが属性を持つ場合、通常のクラスと同様に表す関連クラス関連クラスが他のクラスと関連を持つことがある

62 関連クラスのイメージ aさん営業部 (a,営業部) 社員組織 bさん開発部経理部
cさん dさん (b,開発部) (c,開発部) (d,経理部) 関連クラス：所属関係Rのグラフ 1 0..* - 配属年月日所属組織社員社員×組織（直積）に属する以下の組（要素）は上のRのグラフ（集合）には含まれない ※社員と組織の間にリンクがないから (a, 開発部), (a, 経理部), (b, 営業部), (b, 経理部), (c, 営業部), (c, 経理部), (d, 営業部), (d, 開発部）

0..* 0..* プロジェクト参画プロジェクト : プロジェクト 0..* ロールエンジニア参画
1..* 0..* ロール 0..* 0..* プロジェクトエンジニア関連クラスによって表現されたモデルは、限定子という別の方法を使って表すことができる 63 関連クラスを別の方法で表す限定子限定子参画プロジェクト：プロジェクト限定子名型省略可左のモデルエンジニアとプロジェクトには参画という関連があり、参画に対してあるロールを担っている右のモデルエンジニアが参画プロジェクト毎の自分のロールを知っているこれを「参画」にしてもよい。その場合は多重度が0..1 多重度の最小値は0になる（参画していないプロジェクトに対するロールはないため）必要なければ限定子の型を表す概念を図に描かなくてよい（限定子の型はStringやDate の場合もある）

3つ以上の概念間の関連を引くことができる。UMLではこれをn項関連（nは関連に関わる概念の数）という例）社会人向け外国語学習塾があり、6か国（英語、中国語、韓国語、フランス語、ドイツ語、ロシア語）を学ぶことができる。受講時間帯は月～金の19時～20時と固定であり、どの日も全ての外国語の授業を行っている。生徒は曜日毎に学びたい外国語を選択できるが、どの曜日にどの外国語を学ぶかを事前に登録しておくこれを生徒AがX曜日にYという外国語を受講する、として以下の3項関連のモデルで表現する n項関連も、関連が属性をもったり、関連を持つ場合は、2項関連と同様、関連クラスでそれを表現することができる
64 n項関連曜日外国語生徒 1..* 1..5 1..6 受講する

n項関連も、関連が属性や関連を持つ場合は、2項関連と同様、関連クラスでそれを表現することができるまた関連クラスを限定子を使って表現することもできる 65 n項関連の関連クラス、限定子曜日外国語生徒 1..* 1..5
1..6 受講する - 出席日数 - 開始年月日学習状況曜日外国語生徒 1..* 1..5 1..6 関連クラス受講外国 : 外国語受講曜日 : 曜日 0..1 - 出席日数 : int - 開始年月日 : int 　学習状況　生徒受講曜日：曜日受講外国語：外国語限定子 n項関連の場合はn-1個の限定子名が列挙される関連クラス限定子

UMLでは全体を表す要素と部分を表す要素が紐づくことを表す関連として、集約（Aggregation）、とコンポジションという関連が用意されている 66 集約／コンポジション会社社員部署 0..* 1
0..* 1 集約白いダイヤモンドコンポジション黒いダイヤモンド会社全体は社員から構成されている会社全体は部署から構成されている全体部分部分

集約とコンポジションはどちらも全体 – 部分の関係を表す制約的には集約よりコンポジションのほうが強い。コンポジションには特に以下の制約が課される • 部分の要素に紐づく全体の要素はちょうど１つ（0でもなければ2以上でもない） • 全体側について、同一概念の要素が１つになるのはもちろん、異なる概念が全体になる場合でも、１つの概念の１つの要素の部分になる
• 全体の要素が削除されたら、それにリンクする部分側の要素も削除されるしかし、集約やコンポジションと通常の関連の差はあいまいで、人により様々な意味合いを持って使われている。Martin Fowler氏は著作「UML Distilled」の中で集約は使わないことを推奨している 67 集約とコンポジションの違い顧客氏名 1 社員 1

1つの要素をいくつかの構成要素に分割するとき → コンポジションを使う属性を関連で表すとき → 集約を使うその他 → 通常の関連を使う 68
集約／コンポジション／関連どう使い分ける

集約はコンポジションより制約がゆるい。コンポジションに要求される以下の制約は、集約では要求されない • 部分の要素に紐づく全体の要素はちょうど１つ（0でもなければ2以上でもない） • 全体の要素が削除されたら、それにリンクする部分の要素も削除される値がユニークであるかそうでないかを多重度で表す 69 関連で表した属性は集約で表す
会員住所 1 0..* メールアドレス 0..5 0..1 同一住所を持つ会員が複数いる場合がある（家族等）メールアドレスはユニークでなければならない

属性と同じく、関連にも派生がある合成 2つの関連f, gに対し、fが概念Xと概念Yとの間の関連で、gが概念 Yと概念Zとの間の関連であるとき、以下の関係のグラフを成り立たせる関連をfとgの合成関連といい、g〇 fと表す 70 派生関連（合成）社員
資格 Money - 保有資格 0..* 0..* - 資格手当 0..1 0..* - 資格手当 0..* G(g〇 f) = {(x, z) ∈ X×Z | ∃y∈Y((x, y)∈G(f) ∧ (y, z)∈G(g)) } ※関連に{ordered}制約がつく場合を除く資格手当〇保有資格派生関連（合成） UMLでは関連名の前に／を付記して派生であることを示す

導出属性や他の関連等から、なんらかの計算を行って求められる関連例）シーザー暗号化された文字列から、候補となる鍵（ずらした分の文字数）への関連 71 派生関連（導出）この関連は、アルファベットからなる暗号化された文字列と、アルファベット 26文字の一般的な頻出割合を用いることで推測できる G Hutton,
Programming in Haskell Second Edition. CAMBRIDGE UNIVERSITY PRESS を参照 - アルファベットからなる暗号化された文字列シーザー暗号により暗号化された文字列 0から25までの整数 - 候補鍵 1 0..* アルファベットの頻度リスト有理数アルファベット : アルファベット 1 アルファベット文字列の各文字を正の方向へ0～25文字数だけずらす暗号化の手法。ずらす文字数を鍵という。例） HAL → IBM（鍵=1） ※派生属性や派生関連は操作区画に操作として書かれることもある

72 スーパタイプ／サブタイプ

集合Aの任意の元が集合Bの元であるとき、AはBの部分集合であるといい A ⊂ B と書く • AはAの部分集合である • ∅は任意の集合の部分集合である
• A ⊂ B かつ B ⊂ A ならば A ＝ B • A ⊂ B かつ A ≠ B ならば AはBの真部分集合という部分集合 A a b c 73

A∩B：＝｛x|x∈Aかつx∈B｝を集合Aと集合Bの共通部分という A∪B：＝｛x|x∈Aまたはx∈B｝を集合Aと集合Bの合併（和集合）という A - B ：＝｛x|x∈Aかつx∉B｝をAとBの差という共通部分・合併・差共通部分合併
差 A B A B A B 74

75 部分集合はスーパタイプ／サブタイプで表す会員偶数ゴールド会員偶数５の倍数偶数かつ5の倍数５の倍数偶数
５の倍数偶数５の倍数会員ゴールド会員特化汎化包含する側の概念スーパータイプ包含される側の概念サブタイプ

サブタイプはスーパタイプの属性や関連を持つ。これを属性・関連の継承という • スーパタイプに属する要素は、同時にスーパタイプに属する要素でもあるから • ゴールド会員であるAさんは、会員である • 男性であるBさんは、人間である •
概念モデルでは継承は、属性やメソッドの再利用として考えるのではない 76 属性・関連の継承 A a b c サブタイプの要素は A a b c スーパタイプの要素でもある

• サブタイプがさらにサブタイプを包含する場合がある • この系列は何段階続いてもよい 77 サブタイプのサブタイプ A ⊃ A’ ⊃
A’’ ⊃ ・・・例） • 哺乳類 ⊃ 獣亜綱 ⊃ 有胎盤類 ⊃ 北方真獣類 ⊃ 真主齧類 ⊃ 霊長目 ⊃ ヒト • 複素数 ⊃ 実数 ⊃ 有理数 ⊃ 整数 ⊃ 自然数自然数整数実数有理数複素数

集合系 • 元が全て集合である集合を集合系という ※上の意味での集合を集合族と呼ぶ著書もあるが、当講義では、集合族とはある添字集合から上の意味での集合系への写像のこととし、集合系と集合族を区別する • 例）東京に本社がある株式会社の社員の集合の集合 78 集合系
東京に本社がある株式会社の社員の集合の集合 A社の社員の集合 A社の社員の集合 B社の社員の集合 B社の社員の集合集合系

巾（べき）集合 • 集合Aの部分集合全体からなる集合系をAの巾（べき）集合という • 例）A＝｛a, b, c｝のべき集合 {∅, {a},
{b}, {c}, {a, b}, {a, c}, {b, c}, {a, b, c}} ※べき集合の要素数は２の元集合の要素数乗 • 集合Aの巾集合を (A) 、 (A)、2A などと書く • 巾集合は英語ではpower setという 79 巾（べき）集合 (A) A Aの巾集合

Aを任意の集合としたとき、Aの巾集合の任意の部分集合をA の部分集合系という例）A＝｛a, b, c｝の部分集合系 • (A)= {∅, {a}, {b},
{c}, {a, b}, {a, c}, {b, c}, {a, b, c}} • {{a}, {b}, {c}} • {{a} , {a, b}, {a, c}, {a, b, c}} 80 部分集合系 (A) A (A)の部分集合：Aの部分集合系 A Aの部分集合系 Aの部分集合系

集合Aとその部分集合系X(⊂ (A)) が以下の両条件を満たすとき、 XはAの直和分割であるという ① Xの全要素の合併はAと等しい ② Xの任意の要素X1, X2 に対して、X1
≠ X2 ならばX1 ∩ X2 ＝∅ XがAの直和分割であるときAはXに属する集合の直和であるという 81 直和分割・直和 (A) A X⊂ (A) A Aの直和分割 Aの直和分割ではない（②を満たさない）

集合「人」に対して ① 「性別が女性」、「性別が男性」、のみを要素とする、「人」の部分集合系Xは、「人」の直和分割である ② 「国籍が日本」、「国籍がアメリカ」、「国籍が中国」、「国籍がこれら以外」、のみを要素とする、「人」の部分集合系Y は、「人」の直和分割である ③ ①の直和分割に、②の任意の要素を加えたものは、直和分割
ではない（逆もしかり）集合はいくつかの直和分割を持つ女性男性人人の性別による直和分割日本 U.S.A 中国人人の国籍による直和分割女性男性人人の直和分割ではない部分集合系 82 日本

制約 disjoint で表すその他があるかないかを以下の制約で表すその他有 complete その他無 incomplete 83 直和分割のクラス図表現
人日本人アメリカ人中国人 {disjoint, incomplete} 人男性女性 {disjoint, complete}

• 概念Aに対して2つ以上の直和分割を定めるとき、 Aは多重分類されているという 84 多重分類人男性女性日本人 {disjoint,
complete} :性別 :国籍アメリカ人中国人 {disjoint, incomplete} {incomplete} :社会人社会人 {incomplete} :学生学生矢頭を共有しているサブタイプは、同じ直和分割の要素どうしである直和分割につけられた名前。コロンの後に続けて書く。これをパワータイプ（後述）の名前という disjoint ／ overlapping incomplete ／complete

物事を分類・整理したい • 概要から詳細へ • 一般から個別へ • 抽象から具体へスーパタイプからサブタイプへの特化となるサブタイプ側で新たな属性や
関連が順次追加される 85 特化を引き起こす動機哺乳類獣亜綱単孔類有胎盤類有袋類アフリカ獣類異節類北方真獣類真主齧類ローラシア獣類霊長目齧歯目ウサギ目ヒヨケザル目ツパイ目ヒト特化

別の概念を区別せずに見るときがある例）パーティパターン：人と組織は別の概念だが、連絡帳にのせるときはどちらも区別せず、名前、メールアドレス、電話番号を記録する汎化する前にサブタイプがそれぞれもっていた同種の属性を、汎化したあとにスーパタイプに持たせる 86 汎化を引き起こす動機１ - 電話番号
- メールアドレス - 氏名人 - 代表電話番号 - 代表メールアドレス - 組織名組織人組織パーティ人組織人組織 - 連絡用電話番号 - 連絡用メールアドレス - 名称パーティ（人／組織）アドレス帳 0..* - 電話番号 - メールアドレス - 氏名人 - 代表電話番号 - 代表メールアドレス - 組織名組織パーティ（人／組織）連絡帳 0..* アドレス帳アドレス帳

異なる概念が共通部分を持っている ※異なる集合に属する要素が存在する。それらを重複してもたず１要素として管理したい例）A病院では医師と患者（患者カードを発行されている人）を別に台帳管理していたが、医師の中にも当病院で受診し患者カードを発行された者がいて住所や氏名などが2重管理されていた汎化する前にサブタイプがそれぞれもっていた同種の属性を、汎化したあとにスーパタイプに持たせる 87 汎化を引き起こす動機２
- 住所 - 専門 - 生年月日 - 氏名 - 医師ID 医師 - 住所 - 生年月日 - 氏名 - 患者番号患者 - 住所 - 専門 - 生年月日 - 氏名 - 医師ID 医師 - 住所 - 生年月日 - 氏名 - 患者番号患者患者としても登録されている医師 - 専門 - 医師ID 医師 - 患者番号患者 - 住所 - 生年月日 - 氏名 - 人材ID 病院人材医師患者医師患者医師患者病院人材

直和分割による分類では、静的分類（要素は同じ１つの部分集合の要素であり続ける）としてモデル化されることが多いしかしUMLでは、要素が直和分割の部分集合を移動することをモデルとして表現できるこうした直和分割による分類を表現したものを動的分類という例）商品は「販売予定商品」の要素から始まり、「販売中商品」の要素として市場に売り出され、販売終了により「販売終了商品」の要素になる 88 動的分類 -
商品番号商品 - 販売予定単価 - 販売商品仮名 - 販売開始予定年月日販売予定商品 - 販売単価 - 販売商品名販売中商品 - 販売終了年月日販売終了商品 <<動的>> 商品販売予定商品販売中商品販売終了商品動的分類を表すステレオタイプ

動的分類は、Javaなどの主流のプログラミング言語ではそのまま実装できないため、概念モデルにおいてそれを使用することに反対の意見もあるそうした反対の立場からは、動的分類は用いずにステートパターンを使って同様のことをモデル化する方法がとられることが多い ※直和分割毎にステート型があるモデルとするのが標準 89 動的分類に対する反対意見 - 商品番号
商品商品販売状態 1 1 - 販売予定単価 - 販売商品仮名 - 販売開始予定年月日商品販売状態‐販売予定 - 販売単価 - 販売商品名商品販売状態‐販売中 - 販売終了年月日商品販売状態‐販売終了商品販売状態販売予定商品販売中商品販売終了商品商品

以下のケースでも実は動的分類がある 90 動的分類をもう少し医師患者病院人材病院人材医師患者医師
非医師直和分割：医師と非医師非医師医師患者非患者直和分割：患者と非患者患者非医師病院人材医師非医師 <<動的>> {disjoint, complete} 患者 {disjoint, complete]} <<動的>> 非患者病院人材医師 <<動的>> {incomplete} 患者 {incomplete} <<動的>> 非医師、非患者を省略

こちらの動的分類についても、先のスライドと同様、 Javaなどの主流のプログラミング言語ではそのまま実装できないため、動的分類で表現することに反対の意見がある代替案としてのモデルが以下ステートパターンと異なり、ここでは医師、患者それぞれの要素を直接紐づけている比喩的にいえば、医師という帽子と患者という帽子があり、人はそれをかぶったり、ぬいだりできかつ同時に１つだけだったり２つともかぶったりできて、かぶっている間だけその役割を担っていると考えるこのようなモデルをロールパターンというロール
役割の帽子医師（という役割／帽子）病院人材病院人材医師 0..1 1 患者 0..1 1 91 患者（という役割／帽子）

インスタンス（要素）が他のオブジェクト型（概念）のサブタイプであるようなオブジェクト型（概念） 92 パワータイプ A power type is an object
type whose instances are subtypes of another object type. James J. Odell, Advanced Object-Oriented Analysis & Design Using UML, CAMBRIDGE UNIVERSITY PRESS より引用保険証券損害保険医療保険生命保険 {disjoint, incomplete} : 保険の種類保険の種類 1 * パワータイプ以下の要素が属する生命保険医療保険損害保険コロンに続けてパワータイプの型名を書く。これによりサブタイプとパワータイプが結びつくパワータイプの使いどころサブタイプに属する個々の要素が持つ属性や関連とは別に、サブタイプそのものが持つ属性や関連がある場合にパワータイプの属性や関連としてそれらを表す

概念としての解釈概念モデルとしては、パワータイプの要素とサブタイプは同じものを二重に表現したものである。よって、サブタイプのいずれかをモデルから削除したときには、対応するパワータイプの要素も同時に削除されたものとみなす多重分類がある場合、パワータイプは複数になる場合があるサブタイプがさらにサブタイプを持つ場合、パワータイプにその階層を表す関連が持たれる 93 パワータイプ保険証券損害保険
医療保険生命保険 {disjoint, incomplete} : 保険の種類保険の種類 1 * 保険カバレージタイプ終身保険自動車保険火災保険地震保険団体保険個人保険 {disjoint, complete} : 保険カバレージタイプ 1 * - サブタイプ - スーパタイプ 0..* 0..1

対応：A → Bに対して、Aの部分集合であるA‘に対して対応：A’ → B を考えたとき、この対応をの A’への制限といい、|A’と書く。写像についても同様 94
対応／写像（関連）の制限対応の制限 A A‘ B B‘ A A‘ B B‘

会員購入 - 購入 - 購入者 0..* 1 有料会員獲得ポイント数
: int 有料会員購入 - 購入|有料会員 - 購入者|有料会員購入 0..* 1 会員購入 - 購入 - 購入者 0..* 1 有料会員獲得ポイント数 : int 有料会員購入 - 購入|有料会員 - 購入者|有料会員購入 0..* 1 対応／写像先も部分集合になることを明示する対応／写像の制限はどういう時に使うか１会員有料会員購入有料会員購入会員有料会員購入有料会員購入対応の制限このリンクが許されることになる対応の制限こちらに対応の制限を指定しないと

多重度が変わる（狭くなる） 96 対応／写像の制限はどういう時に使うか２プロジェクトロールエンジニア PG SE PL PL
PG SE PLはプロジェクト毎に必ず一人プロジェクトロール 0..* 1 プロジェクトリーダエンジニア - 参画 0..* 0..* - Γ|プロジェクトリーダ 1 0..* 多重度が0..*から1に変わった対応の制限で多重度を変えるときは、制限されないときの多重度より範囲を広げてはならない。狭くなるようにすること

対応／写像の制限はUMLでは関連の制約である {redefines}で表現する表記 {redefines スーパタイプ側の関連端名} 97 対応／写像の制限のUMLでの表記会員購入 -
購入 - 購入者 0..* 1 有料会員獲得ポイント数 : int 有料会員購入 {redefines 購入者} {redefines 購入} 会員有料会員購入有料会員購入会員有料会員購入有料会員購入このリンクが許されることになるこの制約をつけるかつけないかでモデルの意味が変わる。2つ前のスライドのベン図を参照のこと

リンクの一部に特別な意味がある場合、制約{subsets}でそれを表す表記 {subsets 特別な意味が含まれる関連端名} 下のモデルでは以下が表されている上の関連チームには複数の選手が所属する真ん中の関連所属している選手の一部はレギュラーである下の関連
所属している選手のうち1名がキャプテンである 98 subsets 選手チーム - 所属 1 0..* {subsets 所属} - レギュラー 1 0..* {subsets 所属} - キャプテン 1 0..1 選手全てのリンクは所属赤いリンクはレギュラー点線のリンクはキャプテンチーム

99 変化

- 消費税 - / 注文金額合計 - 注文年月日 - 注文番号注文
- / 注文金額 - 注文個数 - 注文枝番 - 注文番号注文明細 1..* - 商品名 - 商品単価 - 商品番号商品 - 注文品 0..* 1 よくあるモデル 100 商品単価が変わったら注文金額 = 注文品.商品単価 * 注文個数でも注文の半年後に商品単価が改訂されたら、半年前の注文の注文金額はわからなくなる

履歴で表す。大きくは以下の3パターン（か？） 101 履歴 1. 商品と同じ項目を履歴に持たせる 2. 変わった項目のみ履歴に持たせる 3. 商品と同じ項目を持つ履歴に対して関連が引かれる
- 消費税 - / 注文金額合計 - 注文年月日 - 注文番号注文 - 商品履歴番号 - / 注文金額 - 注文個数 - 注文枝番 - 注文番号注文明細 1..* - 商品名 - 商品単価 - 商品番号商品 - 注文品 0..* 1 - 商品単価 - 商品名 - 商品履歴番号 - 商品番号商品履歴 0..* - 消費税 - / 注文金額合計 - 注文年月日 - 注文番号注文 - 商品履歴番号 - / 注文金額 - 注文個数 - 注文枝番 - 注文番号注文明細 1..* - 商品名 - 商品単価 - 商品番号商品 - 注文品 0..* 1 0..* - 変更値 - 変更項目 - 商品履歴番号 - 商品番号　商品履歴　 - 消費税 - / 注文金額合計 - 注文年月日 - 注文番号注文 - / 注文金額 - 注文個数 - 注文枝番 - 注文番号注文明細 1..* - 商品名 - 商品単価 - 商品番号商品 - 注文品 0..* 1 - 商品単価 - 商品名 - 商品履歴番号 - 商品番号商品履歴 0..* 商品履歴番号が必要商品履歴番号が必要

履歴バイテンポラルデータモデルファウラーのパターンイベントソーシング 102 概念モデルを脅かすもの・・・それは時間

103 メタファー

隠喩比喩法の一。「…のようだ」「…のごとし」などの形を用いず、そのものの特徴を直接他のもので表現する方法。「花のかんばせ」「金は力なり」の類。暗喩。隠喩法。メタファー。、暗喩、比喩などが使われる XPの初版のプラクティスに含まれていた 104 メタファー

C3プロジェクトのメタファー • 給与支払システムは組立ライン概念モデルでもメタファーを用いると有効なことが多い • 110番システムは受発注と在庫引当でモデル化した • ビジネスシステムでは物流や生産管理をメタファーとして用いると有効なことが多い
105 XPのメタファー代表例

106 実践

従来オブジェクト指向の人々に推奨されてきた方法方法１：要件定義書やユースケース記述等の文書から、主に名詞に着目して概念候補を抽出方法２：ドメインエキスパートにヒアリングして、主に名詞に着目して概念候補を抽出従来日本のデータモデル派の人々に推奨されてきた方法方法３：画面、帳票から概念候補を抽出実際にはこの３つの方法を組み合わせて（思考的には行ったり来たりしながら）概念候補を抽出することになる 107
概念の識別方法

しかし、漠然と名詞を抽出する、画面・帳票から概念を見つけるといっても、どうしたらよいか考えてしまうそんなときには、先人のノウハウを参考にしよう 108 概念抽出時のTIPS ‐ 概念パターン

109 PLAN – DB THモデル

• 経営資源を表す概念 • 社内組織（事業部、部、課、社員、協力会社、その分類の性別、資格など） • 社外組織（顧客、卸、銀行、その分類の業種、地域など） • 設備（工場、建機、金型、事務所など） • 品役（商品、資材、サービス、その分類など）
• 金（資本金、借入金、勘定科目など） • その他 • 上記のような概念を以下の３つの視点で分類して抽出する • オカレンスリソース • 経営資源そのものを表す。一般的に識別番号を持つ • タイプリソース • 経営資源の分類観点 • リソース関連 • リソース間の関連を表す • 要素のライフサイクルは一般的に長く、その間で属性値や関連が更新されることがある • イベントの４W１Hの指し先として機能する（主にオカレンスリソース） • 共用度が高 110 THモデル：リソース

• ビジネス遂行中に発生した出来事（事実／Fact）を表す概念 • 以下の３つに分類できる • 通常イベント • 発生タイミングが定まっていないもの • 受注、出荷、請求、入金、生産指図、出勤、機器故障
など • 定時イベント • 発生タイミングに周期性があるもの • 給与支払い、月次売上報告など • 異動イベント • オカレンスリソースや関連リソースの生成／消滅／属性値変更／関連変更を起動するイベント • 採用 → 社員 • 購入 → 固定資産 • 所属移動 → 所属（部署と社員の間の関連リソース） • 昇進 → 社員の役職（属性） • 契約金額増額 → 契約の金額（属性） • 要素のライフサイクルはリソースに比べて短く、入力ミス等特殊な場合を除いて属性や関連は更新されない • 属性としては４W１H（What、Who／Whom、Where、When、How much）を持つのが一般的。これらの指し先はリソースとなる • 共用度が低 111 THモデル：イベント

• 在庫 • イベントにより常時変化する在庫数や残高を管理しているものを概念として把握したもの • 商品在庫、預金残高など • 断面
• リソースや在庫のある時点（年末、4半期末、月末、週末、日末など）の状態の記録を概念として把握したもの • 月末商品在庫、商品履歴、貸借対照表 • 要約 • 通常イベント、定時イベントの主に数値属性のある期間の要約の記録を概念として把握したもの • 四半期別商品別売上実績、月次社員別稼働実績、損益計算書 • 要約のキーは期間に加えて、他のオカレンスリソース（部署、社員、顧客など）が用いられる場合がある • 要約されるデータは合計、平均、最大、最小、中央値、最頻値、最近値など 112 THモデル：在庫、断面、サマリー

113 THモデル例リソース系 - 支店名 - 支店コード支店 - 部署名
- 部署コード部署 1..* 1 - 子部署 - 親部署 0..* 0..1 - 社員名 - 社員番号社員 0..* 1 - 性別名 - 性別コード性別 0..* 1 - 異動データ - 異動年月日 - 異動番号 - 社員番号社員異動 0..* 1 - 異動名 - 異動コード異動コード 0..* 1 - 地域名 - 地域コード地域 - 業種名 - 業種コード業種 - 住所 - 倉庫名 - 倉庫番号倉庫 - 取引先番号 - 顧客フラグ - 届先フラグ - 電話番号 - 住所 - 取引先名取引先届先顧客届先フラグ = True 顧客フラグ = True 0..* 1 0..* 1 0..* 1 - 商品コード - 地域コード出荷倉庫 - 単価 - 商品名 - 商品コード商品 - 品種名 - 品種コード品種 0..* 1 - 受注ステータス名 - 受注ステータスコード受注ステータス 1..* 1 0..* 1 0..* 1 異動イベントタイプリソースオカレンスリソースリソース関連地域と商品によって出荷する倉庫が決まるというビジネスルールを表している

114 THモデル例イベント系 - / 受注合計額 - 納入年月日 - 受注年月日
- 受注番号受注 - 受注枝番 - 受注番号 - / 受注金額 - 受注数受注明細 1..* 1 - 安全在庫数 - / 未引当在庫数 - / 実在庫数 - 倉庫番号 - 商品コード在庫 - / 日末未引当在庫数 - 年月日 - 商品コード - 倉庫番号日末在庫 0..* 1 - / 出荷合計金額 - 出荷年月日 - 出荷番号出荷 0..* 1 - / 出荷金額 - 出荷量 - 出荷枝番 - 出荷番号出荷明細 1..* 1 1 0..* - / 売上個数 - / 売上実績額 - 年月 - 商品番号 - 顧客番号 - 支店コード売上実績 0..* 1 0..* 1 - / 売上実績額 - 年 - 業種コード売上実績A - / 売上実績額 - 年月 - 品種コード - 支店コード売上実績B 0..* 1 1 0..* 1 0..* - 受注ステータス名 - 受注ステータスコード受注ステータス 0..* 1 - 社員名 - 社員番号社員 - 受注担当者 0..* 1 届先 - 届先 0..* 1 - 支店名 - 支店コード支店 - 部署名 - 部署コード部署 0..* 1 0..* 1 1..* 1 1 0..* / 担当支店顧客 1 0..* / 受注顧客 - 単価 - 商品名 - 商品コード商品 0..* 1 - 住所 - 倉庫名 - 倉庫番号倉庫 1 0..* / 出荷倉庫 - 単価 - 商品名 - 商品コード商品 1 0..* - 住所 - 倉庫名 - 倉庫番号倉庫 0..* 1 通常イベント在庫断面要約

• 本日は割愛 • ２つのクラスの協調に関するパターンとして12種類のパターンを定義 • これらパターンの紹介と、協調のルールや98個のモデリングの原則をまとめている
115 ストリームラインドオブジェクトモデリング

カテゴリとパターンプレイヤ 116 ストリームラインドオブジェクトモデリングカテゴリパターンプレイヤ人アクタロール場所場所
外部の場所モノ品目特定品目組立品部品コンテナコンテンツグループメンバ事象トランザクションコンポジットトランザクション明細後続トランザクション

＃名称説明原則 11 人の原則システムに関与しているそれぞれの人をモデリングする際には、アクタオブジェクトを使用します。同様に、１つのエンティティのようにシステムに関与している人々の組織をモデリングする際にも、アクタオブジェクトを使用します。原則
12 コンテキストの原則人または組織が、追跡され記録されるアクションを行う場合は必ず、関与するコンテキストがあります。その人または組織が異なる許可や情報を必要とするアクションは、異なるコンテキストに属します。原則 13 ロールの原則あるエンティティが関与するコンテキストごとに、別々のロールオブジェクトを作成します。そのコンテキストで必要な情報と許可を、そのロールに置きます。原則 14 場所の原則記録されるアクションが発生する位置をモデリングするために、場所オブジェクトを使用します。階層的な位置をモデリングするために、場所を含む外部の場所を使用します。場所または外部の場所を異なるコンテキストで使用する場合は、ロールオブジェクトを使用します。原則 15 モノの原則モノは、２つのオブジェクトを用いてモデリングします。つまり、類似したモノを含む集合を定義する記述として振る舞う品目と、特化したモノを集合内のモノと区別する特定品目です。異なるコンテキストにあるモノの使用は、ロールオブジェクトを使用してモデリングします。 117 オブジェクトの識別に関する原則 1/2

＃名称説明原則 16 モノを集約する原則モノのコンテナは、コンテンツオブジェクトとともに、コンテナとしてモデリングします。モノの分類は、メンバオブジェクトとともに、グループとしてモデリングします。モノの全体は、部品オブジェクトの組立品としてモデリングします。原則
17 事象の原則ある場所で１つのモノと相互作用する人の事象は、トランザクションオブジェクトとしてモデリングします。ある時点での相互作用は、１つのタイムスタンプを持つトランザクションとしてモデリングします。期間の事象は、複数のタイムスタンプを持つオブジェクトとしてモデリングします。原則 18 履歴の原則人、場所、モノについての履歴的、または時間に重要な意味がある事象の情報を記録するには、期間を持ったトランザクションを使用します。原則 19 コンポジット事象の原則ある場所で複数のモノと相互作用する人は、コンポジットトランザクションとしてモデリングします。関与するモノごとに、特定の相互作用の詳細を獲得するために、明細を含めます。原則 20 後続事象の原則前の事象に後続し事象に依存した事象は、後続トランザクションでモデリングします。 118 オブジェクトの識別に関する原則 1/2

協調パターン 119 ストリームラインドオブジェクトモデリングロール 0..* 1 アクタ外部の場所場所 1..*
0..1 品目特定品目 0..* 1 組立品部品 1..* 0..1 コンテナコンテンツ 0..* 0..1 グループメンバ 0..* 0..* コンポジットトランザクショントランザクションロール 0..* 1 トランザクション場所 0..* 1 トランザクション特定品目 0..* 1 明細 1..* 1 特定品目明細 0..* 1 トランザクション後続トランザクション 0..* 1

120 アクタ－ロール人顧客 0..1 1 従業員 0..1
仲介者 0..1 1 企業サプライヤ 0..1 1 ディストリビュータ 0..1 1 メンバー議長人管理者 0..1 1 0..1 1 0..1 1 アクタロールアクタロールアクタロールアクタロールコンテキスト内の人、組織、場所、モノの関わりをモデリングするために使用する • アクタは、ゼロ個以上の多くのロールを知っているが、一般的に、各種類の１つだけをとる • ロールは、そのアクタのコンテキスト内での特定のビュー（見え方）を表現する。ロールはアクタに依存しており、アクタなしでは存在できないロール 0..* 1 アクタ外部の場所場所 1..* 0..1 品目特定品目

121 外部の場所－場所製造工場の倉庫搬出場所 1..* 1 搬入場所 1..*
1 空港ゲート 1..* 1 外部の場所場所外部の場所場所ロール 0..* 1 アクタ外部の場所場所 1..* 0..1 品目特定品目 0..* 1 組立品部品 1..* 0..1 事象が発生する位置の階層をモデリングするために使用する • 外部の場所は、ゼロ個以上の場所を含むコンテナである • 場所は、最大１つの外部の場所を知っている。場所の存在は、その外部の場所の所在に依存する配送物製造工場の倉庫搬入場所 1..* 1 0..* 1 荷物保管場所 1..* 0..1 荷物 1..* 1 0..* 1 トランザクション場所外部の場所場所外部の場所コンポジットトランザクション

122 品目－特定品目ビデオタイトルビデオテープ 0..* 1 ビデオタイトルビデオテープ
0..* 1 映画タイトル DVDタイトル DVD 0..* 1 0..* 1 0..* 1 品目特定品目品目特定品目品目特定品目いくつかの異なる変形に存在するモノをモデリングするために使用する • 品目は、ゼロ個以上の特定品目のための共通の記述ある • 特定品目は、１つの品目を知り、それに依存する。特定品目のプロパティの値は、同一の品目によって記述される特定品目を他の特定品目と区別する 0..* 1 外部の場所場所 1..* 0..1 品目特定品目 0..* 1 組立品部品 1..* 0..1 コンテナコンテンツ 0..* 0..1

123 組立品－部品ワークステーションコンポーネント 1..* 0..1 ワークステーションコンポーネント
1..* 0..1 サブコンポーネント 0..* 0..1 組立品部品組立品部品組立品部品外部の場所場所 1..* 0..1 品目特定品目 0..* 1 組立品部品 1..* 0..1 コンテナコンテンツ 0..* 0..1 グループメンバモノの総体をモデリングするために使用する • 組立品は、１つ以上の部品を持つ。部品が組立品のプロパティを決定し、その組立品は部品なしでは存在できない • 部品は、同時に、最大１つの組立品に属する。部品は、単独で存在できる

パレットケース 0..* 0..1 124 コンテナ－コンテンツコンテナコンテンツ
パレットケース 0..* 0..1 トラック 0..* 0..1 コンテナコンテンツコンテナコンテンツモノの入れ物をモデリングするために使用する • コンテナは、ゼロ個以上のコンテンツオブジェクトを保持する。組立品とは異なり、空であることができる • コンテンツオブジェクトは、同時に、最大１つのコンテナ内に存在できる。コンテンツオブジェクトは、それ自体で存在できる品目特定品目 0..* 1 組立品部品 1..* 0..1 コンテナコンテンツ 0..* 0..1 グループメンバ 0..* 0..*

125 グループ－メンバグループメンバカテゴリ製品 0..* 0..*
カテゴリ製品 0..* 0..* 0..* 0..* グループメンバグループメンバモノの分類をモデリングするために使用する • グループは、ゼロ個以上のメンバを含む。グループは、オブジェクトを分類するために使用される • メンバは、部品やコンテンツオブジェクトとは異なり、１つ以上のグループに属することができる組立品部品 1..* 0..1 コンテナコンテンツ 0..* 0..1 グループメンバ 0..* 0..*

購入注文人仲介者販売注文顧客 0..1 1 0..1 1 1
0..* 0..* 1 販売担当者 0..1 1 0..* 1 126 トランザクション－ロールアクタロールトランザクション事象に関わるものを記録するために使用する • トランザクションは、１つのロール、つまりその相互作用の実行者を知っている • ロールは、ゼロ個以上のトランザクションを知っている。ロールは、トランザクションに関与する人、組織、モノ、あるいは場所のコンテキスト上の記述を提供するトランザクションロール 0..* 1 トランザクション場所 0..* 1 トランザクション特定品目 0..* 1 ロールロールトランザクション

配送物製造工場の倉庫搬入場所 1..* 1 0..* 1 127 トランザクション－
場所トランザクション場所外部の場所配送物製造工場の倉庫搬入場所 1..* 1 0..* 1 荷物保管場所 1..* 0..1 荷物 1..* 1 0..* 1 トランザクション場所外部の場所場所外部の場所コンポジットトランザクション事象が発生したところを記録するために使用する • トランザクションは、１カ所で発生する • 場所は、ゼロ個以上のトランザクションを知っている。トランザクションは、その場所で発生した相互作用の履歴を記録するコンポジットトランザクショントランザクションロール 0..* 1 トランザクション場所 0..* 1 トランザクション特定品目 0..* 1 明細 1..* 1 特定品目明細

予約牧場主 0..* 1 雄牛 0..* 1 交配 0..* 1
128 トランザクション－特定品目トランザクションロール特定品目品目１つのモノに関わる事象を記録するために使用する • トランザクションは、１つの特定品目を知っている • 特定品目は、１つ以上のトランザクションへ関与させることができる。トランザクションは、複数の相互作用について特定品目の履歴を記録するコンポジットトランザクショントランザクションロール 0..* 1 トランザクション場所 0..* 1 トランザクション特定品目 0..* 1 明細 1..* 1 特定品目明細 0..* 1

コンテンツ製造者タイトルライセンス条項タイトル条項 1..* 1 コンテンツタイトル 0..* 1 0..* 1
129 コンポジットトランザクション－明細コンポジットトランザクションロール特定品目明細コンポジットトランザクション 0..* 1 トランザクション場所 0..* 1 トランザクション特定品目 0..* 1 明細 1..* 1 特定品目明細 0..* 1 トランザクション後続トランザクション 0..* 1 １つ以上のモノに関わる事象を記録するために使用する • コンポジットトランザクションは、少なくとも１つの明細を含まなければらなない • １つの明細は、１つだけコンポジットトランザクションを知っている。１つの明細は、コンポジットトランザクションに依存しており、コンポジットトランザクションなしでは存在できない

レンタルレンタル明細 1..* 1 ビデオテープ 0..* 1 130 特定品目－
明細コンポジットトランザクション特定品目明細コンポジットトランザクション 0..* 1 トランザクション特定品目 0..* 1 明細 1..* 1 特定品目明細 0..* 1 トランザクション後続トランザクション 0..* 1 複数のモノに関わる事象におけるモノの特定の関わりを記録するために使用する • 特定品目は、ゼロ個以上の明細に関わることができる • １つの明細は、１つの特定品目を正確に知っている。１つの明細は、特定品目のコンポジットトランザクションとの相互作用についての詳細を取り込む

直前の事象の後にだけ発生する事象を記録するために使用する • トランザクションは、いくつかの後続トランザクションを知っている • 後続トランザクションは、正確に１つの直前のトランザクションに後続し、それに依存する 131 トランザクション－後続トランザクション
注文注文明細発送発送明細 1..* 1 1..* 1 0..* 1 0..* 1 製品 0..* 1 トランザクションコンポジットトランザクション後続トランザクションコンポジットトランザクション明細トランザクション明細後続トランザクション特定品目注文注文明細発送発送明細 1..* 1 1..* 1 返品明細返品 1..* 1 0..* 1 0..* 1 0..* 1 0..* 1 トランザクションコンポジットトランザクショントランザクション後続トランザクションコンポジットトランザクション後続トランザクションコンポジットトランザクション明細トランザクション明細後続トランザクショントランザクション明細後続トランザクションコンポジットトランザクション明細 1..* 1 特定品目明細 0..* 1 トランザクション後続トランザクション 0..* 1

• 本日は割愛 • 概念モデリングのパターン集 • 主にモデルに柔軟性を持たせるためのパターンが取り上げられている • パターンは段階的に少しずつ変化
に強くなる流れで説明されている • 過度に適用しないこと。柔軟性が求められることが最初からわかっているところや、そうでないところで後日弾丸が撃ち込まれたところ（後述）にアナリシスパターンを適用するのがよい 132 アナリシスパターン

アロマコーヒーメーカーズ（ACM）社は、事業部、地域、部門、営業所という組織階層からなっていたこれを単純にモデル化すると以下のようになる 133 組織階層しかし、ある日のこと、CEOから、不確実性が高く変化に対して迅速に対応することが求められる現ビジネス環境において、組織構造は常に変更できるようにしたい（例えば地域を廃止してよりフラットにするなど）とのニーズが出された事業部
地域部門営業所 0..* 1 0..* 1 0..* 1

最初の変更 • 地域を廃止しても、地域を表すサブタイプを削除し、要素レべルでリンクをつけかえれば対応できる • モデルの変更は必要ない 134 組織階層組織事業部
地域部門営業所 0..* 0..1 またしてもCEOから、組織階層はこれまでの製品による組織階層だけではなく、それは維持しつつも、市場に対する新たな組織階層も設けることとし、各組織単位はこの両方の組織階層の中に構成されるとの指示が出された

次の変更 • 組織階層を表す関連を増やした 135 組織階層組織事業部地域部門営業所
0..* 0..1 0..* 0..1 製品の組織階層市場の組織階層しかしCEOは、今後も必要であれば、第三、第四の組織階層を設けていきたいとの希望を表明したそのたびに関連線を追加（モデルの変更）するのか

次の変更 • 組織構造は親組織・子組織・組織構造型の3項関連クラスである • このモデルだと新しい階層関係を増やす場合は組織構造型のインスタンスを追加し、そのインスタンスと親組織、子組織の3項のリンクを追加するだけで対応できる（モデルの変更は不要） 136 組織構造組織構造
組織事業部地域部門営業所組織構造型

アナリシスパターンを用いるときの戦略 • 不要な柔軟性は排除する（YAGNI） • しかし一度変更を要求された箇所については、今後変更が求められときに迅速に対応できるよう備えておく We take the first
bullet, and then we make sure we are protected from any more bullets coming from that gun. • そのような箇所にアナリシスパターンを適用する 137 段階的に柔軟性を高めていく

ご清聴ありがとうございました 138

139 関連と集合論このセクションは参考まで講義で説明するかどうかは、要望に応じて

対応 • Ａ, Bを２つの集合とし、ある規則Γ（ガンマと読む）によって、Ａの各元aに対してそれぞれ1つずつＢの部分集合Γ(a)が定められているとき、その規則ΓのことをＡからＢへの対応という • ΓがAからBへの対応であることを Γ：A→Bと表す •
Ｂの部分集合Γ(a)を、 Γによるaの像という Γ(a)は∅でも、Ｂと等しくてもよい対応 A B 対応 1 2 a b c 3 Γ (1) Γ (2) Γ (3) A B 対応 1 2 a b c 3 Γ (1) Γ (2) Γ (3) Γによる1の像空集合の場合もある単集合の場合もある Γ(1) = Γ(2) b∈Γ(1)かつ b∈Γ(3)

写像 • 対応の特別なケース。任意のa∈Aに対してΓ (a)の要素数が１であるとき、その対応を写像という • fがAからBへの写像であることをf：A→Bと表す • Bの部分集合f(a) =
{b}をfによるaの像という • しかし写像の場合は任意のa∈Aに対してfによるaの像は必ず単集合になるので、{b}ではなくbをfによるaの像として、f（a）= bとするのが通常である写像 A B 写像 1 2 a b c 3 f (1) f (3) f (2) A B 写像 1 2 a b c 3 f (1) f (3) f (2)

142 UMLクラス図の関連は対応(一部は写像） 1 2 a b c 3 Γ (1)
Γ (2) Γ (3) 1 2 a b c 3 Γ (1) Γ (2) Γ (3) 1 2 a b c 3 Γ (1) Γ (2) Γ (3) 1 2 a b c 3 Γ (1) Γ (2) Γ (3) d A 1..* B A B 0..1 A B 1 A B 0..* A 1..* B A B 0..1 A B 1 A 1..* B A B 0..1 A B 1 A B 0..* A 1..* B A B 0..1 A B 多重度が１のときは写像

Γ：A→Bを対応とする。このときBの任意の元bに対し、b∈ Γ(a)であるようなA の元a全体のつくるAの部分集合をΔ(b)とする（Δはデルタと読む）と、BからAへの対応Δが定められる。この対応Δ：B → Aを、 Γの逆対応といい、 Γ-1で表す
143 逆対応 A B 対応Γ 1 2 a b c 3 Γ (1) Γ (2) Γ (3) d A B 対応Γ-1 1 2 a b c 3 d

f： A→Bを写像とする 144 写像の逆対応が写像になるとは限らない A B f 1 2 a
b c 3 A B 1 2 a b c 3 f-1 A B f 1 2 a b c 3 A B 1 2 a b c 3 f-1 写像の逆対応が写像になるケース写像の逆対応が写像にならないケース f-1(a)が単集合でない f-1(b)が∅

Γ： A→Bを対応とする 145 写像でない対応の逆対応が写像になることもある A B Γ 1 2 a
b c 3 d A B Γ-1 1 2 a b c 3 d 対応の逆対応が写像になるケース A B Γ 1 2 a b c 3 d A B Γ-1 1 2 a b c 3 d 対応の逆対応が写像にならないケース Γ-1(b)が単集合でない

大きくは次の4種類（0.. を加えるともっと多くの組合せ） • 1 対 1 • 1 対多
• 多対 1 • 多対多 146 逆対応を逆の関連端の多重度で表す A B 1 1 A B 1..* 1 A B A B 1 1 A B 1..* 1..* A B 1..* 1 A B 1 1..* 1 対 1 1 対多多対 1 多対多

集合の要素が集合である、というのも数学的には許されている A = {{2,4,6,8}, {1,3,5,7,9}} ≠ {1,2,3,4,5,6,7,8,9} そう考えると対応も任意のa∈Aに対して1つの集合が定まるので写像といえる（ただしBは冪集合と考えなければならない） 147
対応も見方を変えれば写像だ A B 1 2 a b c 3

写像を関数と呼び変えて、対応も写像（関数）とみなすことで、概念間の関連は関数とみることができる 148 写像は関数所属先部署 :: 社員 -> 部署所属社員
:: 部署 -> [社員] 社員番号 :: 社員 -> 社員番号氏名 :: 社員 -> String 住所 :: 社員 -> Address Eメールアドレス :: 社員 -> Eメールアドレス基本給 :: 社員 -> 日本円部長 :: 部署 -> 社員管理先部署 :: 社員 -> 部署 - 基本給 : 日本円 - Eメールアドレス : Eメールアドレス - 住所 : Address - 氏名 : String - 社員番号 : 社員番号社員 - 部署名 : int 部署 - 所属先部署 - 所属社員 1 1..* - 部長 - 管理先部署 1 0..1 Haskell風に書いてみた関連は、データベースのキーと外部キーの関係だけでなく、関数としてロジックでアウトプットされるものも含まれる関数名関数の始域：クラス名関数の終域：クラス名属性名や関連端名が関数名になる []はリストを表す

集合Ａの任意の元aと集合Bの任意の元bとの順序づけられた組(a, b)の全体からなる集合をＡとＢとの直積といいＡ×Ｂと書くＡ×Ｂ={(a, b)| a ∈Ａ, b ∈
Ｂ} 直積直積 1 2 a b c (1,a) (1,b) (1,c) (2,a) (2,b) (2,c) A B • 直積は、集合Aの全要素、集合Bの全要素の順序づけられた組み合わせ • 集合AとAの直積もある。このときA×AやA2と書く • 3以上（無限でもよい）の集合の直積も考えられる。このとき、A×B×C、A3 等と書く「任意の」とは集合の要素としてどれでもよいから勝手にとって、という意味。勝手に何をとっても条件が成立する、ということになるので、集合の全ての要素が持つ条件を述べるときに「集合Aの任意の要素aに対して条件Pが成り立つ」というような言い方をする

集合A、B、C、Dが以下のとおり与えられたとき、以下の各問に答えよ 1. 直積A×Bを外延的記法で表せ 2. 直積B×Aを外延的記法で表せ 3. 直積A×B×Cを外延的記法で表せ 4. 直積A×Aを外延的記法で表せ
5. 直積A×Dを外延的記法で表せ 150 演習：直積 A={1, 2, 3}, B={x, y}, C={〇, □}, D=∅

1. {(1, x), (1, y), (2, x), (2, y), (3,
x), (3, y)} 2. {(x, 1), (x, 2), (x, 3), (y, 1), (y, 2), (y, 3)} 3. {(1, x, 〇), (1, x, □), (1, y, 〇), (1, y, □), (2, x, 〇), (2, x, □), (2, y, 〇), (2, y, □), (3, x, 〇), (3, x, □), (3, y, 〇), (3, y, □)} 4. {(1, 1), (1, 2), (1, 3), (2, 1), (2, 2), (2, 3), (3, 1), (3, 2), (3, 3)} 5. {} ※任意の集合Aに対してA ✖ ∅ = ∅ ✖ A = ∅ 151 演習:直積答え

対応のグラフ、写像のグラフΓ 対応 Γ ：Ａ → Ｂのグラフとは直積Ａ×Ｂの部分集合Ｇ(Γ)={(a, b) ∈Ａ×Ｂ| b
∈ Γ(a)} 写像 f：Ａ→ Ｂのグラフも直積Ａ×Ｂの部分集合Ｇ(f)={(a, b) ∈Ａ×Ｂ| b = f(a)} 152 対応／写像のグラフ 152 1 2 a b c (1, a) (1, ｂ) (2, c) 対応ΓのグラフＧ(Γ)⊂Ａ×Ｂ A B 3 1 2 a b c (1, a) (3, a) (2, c) 写像fのグラフＧ(f)⊂Ａ×Ｂ A B 3

社員プロジェクト - プロジェクトメンバー - 参画プロジェクト 0..* 0..* - 参画期間
: 期間プロジェクト参画ロール - プロジェクトでの役割 1..* 0..* 関連クラスはいつ必要か対応／写像のグラフが属性／関連を持つとき • プロジェクト参画は参画期間という属性を持つ • プロジェクト参画はロールと関連を持つ i.e. 対応、写像のグラフが、対応／写像の始域となるときプロジェクトでの役割：プロジェクト参画 → ロール参画期間：プロジェクト参画 → 期間 153 対応／写像のグラフは関連クラスで表す関連クラス関連線に点線でつながる

リストは自然数から対象への写像（部分関数）である路線のリスト： ℕ → 停留所 0→渋谷駅, 1→ 道玄坂上,
2→大阪上リストのことを点列ともいう（対称が数値なら数列） 154 リストの数学表現

これ以降没スライドです 155 没スライド

識別子（IDやPK）で管理されないオブジェクト例 • 住所（郵便番号×都道府県×市区町村×丁目番地×建物） • 量（数値×単位）値オブジェクトの特徴 • そのドメイン内の何かの計測結果や説明のための値である •
状態は不変（イミュータブル, immutable）。更新できない。何かの属性値を変えるときには、値オブジェクトを置き換える • 関連する属性を不可欠な単位として組み合わせることで、概念的な統一体を形成する • 等しいかどうかは値の等しさでチェックする／できる IDDD本では値オブジェクトをできる限り使うことを推奨している 156 値オブジェクト（まず教科書的な説明）

何が値オブジェクトか • プリミティブ（言語組み込み）なデータ型 Integer, String, Date, ・・・ • プリミティブなデータ型の取りうる値を制限したり、なんからの形式を持たせたもの
0以上のInteger, メールアドレス, 年月 • 関連する属性を不可欠な単位として組み合わせることで、概念的な統一体を形成するもの住所（郵便番号×都道府県×市区町村×丁目番地×建物）量（数値×単位）本質は • IDで管理する必要のないもの • 状態が変わらないもの 157 値オブジェクト（もう少しつっこんで）

159 クレイグラーマン実践UML

概念のカテゴリ例ビジネストランザクションガイドライン：これらは重要（金銭を含むものである）。これらを識別することから始めよう販売、支払い、予約トランザクション明細行ガイドライン：トランザクションは通常、明細行をともなう。従って次にこれらを検討する販売明細
トランザクションやトランザクション明細行に関与する製品・商品・サービスガイドライン：トランザクションは何か（製品・商品・サービス）に関するものである。次にこれを検討する品物、飛行、座席、食事トランザクションが記録される場所ガイドライン：重要記録簿、元帳、乗員乗客名簿トランザクションに関係する人・組織が担う役割；ユースケースのアクターガイドライン：トランザクションに関与するパーティ（人、組織を包含する概念）について知る必要がある）レジ係、顧客、店舗、モノポリーのプレイヤー、乗客、航空会社 160 クレイグ・ラーマン（実践UML)の概念カテゴリ

概念のカテゴリ例トランザクションやサービスが行われる場所店舗、空港、飛行機、座席注目すべきイベント。通常、時間や場所を覚えていなければならない販売、支払い、モノポリーゲーム、飛行物理的対象ガイドライン：組み込み系やシミュレーションソフトを作るときには特に重要
品物、レジスター、回路基盤、部品、金型、飛行機物事の説明製品仕様、フライト説明カタログガイドライン：物事の説明はカタログに記載されていることが多い製品カタログ、フライトカタログ物や情報の入れ物店、貯蔵箱、回路基板、飛行機、カートコラボレーティングシステム認可システム、航空管制システム財政、労働、契約、法的事項の記録レシート、元帳、保守履歴金融商品現金、小切手、クレジットライン、手形スケジュール、マニュアル、文書といった作業をする上で参照されるもの日次為替リスト、修理マニュアル 161 クレイグ・ラーマン（実践UML)の概念カテゴリ

162 責任関係型責任関係型責任関係パーティ型パーティ期間作業 0..* 0..*
0..* 1 1..* 0..* 1..* 0..* 0..* 1 1 0..* 1 0..* 0..* 1 知識レベル操作レベル

163 観測人観測現象型 0..* 1 0..* 1 測定
カテゴリ観測量 1 0..* カテゴリ 1 0..*

UMLによる概念モデリング入門.pdf

UMLによる概念モデリング入門.pdf

More Decks by Hirohide Yazaki

Other Decks in Technology

Featured

Transcript