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

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

とある概念モデリングの研修で講師として使うマテリアル
以下はもうちょっと追記したいけど時間があれば
 ・変化
 ・メタファー
 ・THモデル
 ・集合論によらないオブジェクト指向

conceptual model
domain model
Object Oriented
UML
Domain Driven Design

2f90d9f4b297fbb9c0245a9024dedf80?s=128

Hirohide Yazaki

February 27, 2020
Tweet

Transcript

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

  2. 所属 株式会社メソドロジック 取締役/CTO 専門 開発方法論、データモデリング、オブジェクトモデリングのコンサルティング 経歴 主に基幹システムの再構築プロジェクトにモデラーとして参画 某都道府県警の通信指令システム(いわゆる110番) テレビ局営報システム(番組編成・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
  3. UMLクラス図を使った概念モデリングの初歩を学ぶ • 概念モデルとは何か • 概念モデリングの効果 • UMLクラス図の表記法。特に概念モデルを描くとき に使われる要素について • 概念モデリングで前提となる数学の考え

    • 実践で使えるアプローチ 2 本日の講義内容
  4. 3 はじめに

  5. Unified Modeling Languageの略称 • 統一されたモデリング言語 • OMG(Object Management Group)が管理 ※OMGは国際的なオープンかつ非営利の技術標準化コンソー

    シアムである • 1980年代後半から1990年代前半にかけてオブジェ クト指向のモデリング言語が数多く台頭したことに対 し、それらを統一する中で生まれた • 最新バージョンは2.5.1(2020年1月25日現在) 4 UMLとは
  6. UML2.5.1では7種類の構造図と7種類の振る舞い 図が用意されている 5 UML構造図および振る舞い図のタクソノミー ダイアグラム 構造図 プロファイル図 クラス図 コンポジット構造図 オブジェクト図

    コンポーネント図 配置図 パッケージ図 振る舞い図 アクティビティ図 相互作用図 ユースケース図 状態マシン図 シーケンス図 コミュニケーション図 相互作用概要図 タイミング図 クラス図 UMLでは クラス図を使って 概念モデルが表現 される
  7. 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
  8. 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 クラス 関連 多重度 関連単名 汎化 コンポジション 制約 限定子 クラス名 属性 再帰関連 属性の型 関連クラス
  9. 言葉のとおり、概念のモデル すなわち、ある目的をもって問題領域を分析あるいは可 視化するために、その問題領域に関わる人々が抱く概念 群を再構成した上で形式的手法で表現すること 8 概念モデル(Conceptual Model)とは

  10. 内包 概念の内容。事物の本質的な特徴とそれらの連関 外延 概念が適用される一定範囲の事物(事物の集まり) 事物 物と事(出来事やアイディア、約束事など) 9 概念 概念 〘哲〙

    ①事物の本質をとらえる思考の形式。事物の本質的な特徴とそれらの連関が概念の内容(内 包)をなし、同一の本質をもつ一定範囲の事物(外延)に適用されることで一般性をもつ。例えば、 人という概念の内包は人の人としての本質的特徴(理性的動物あるいは社会的動物など)であり、外 延はその特徴をもつあらゆる人々である。・・・(略)・・・概念は言語に表現されて「名辞」と呼 ばれ、その意味内容として存在する。・・・(略)・・・ ②大まかで一般的な意味内容。 岩波書店 広辞苑 第七版
  11. 概念のモデルとしての品質/有効性 必要なことをできるだけ表現できること(表現力) 多義的やあいまいさなく意味を伝えられること(形式性) 形式性を確保するために、数学の力を借りよう 特に集合論 • 実は、古いオブジェクト指向の書籍の中には、クラスや オブジェクトを集合を使って説明しているものが多かっ た •

    私と同年代の方や少し先輩の方の著作も同様のものが多 い 10 哲学的に定義された概念を形式的に扱うために
  12. 11 集合論でオブジェクト指向を説明している著書例

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

  14. 13 概念

  15. 集合 集合とは、いくつかのものをひとまとめにして考えた’ものの集まり’ 数学的には“どんなものをとってきても、それがその集まりの中にあるか ないかがはっきりと定まっている“ようなものでなければならない 集合の記法(個々の集合を具体的に表す記法) • 外延的記法:集合の要素を列挙して集合を表す 例){1, 2, 3,

    4, 5, 6, 7, 8, 9} • 内包的記法:条件Pを示して集合を表す{x | P(x)} 例){x | 0 < x < 10, x ∈ ℤ} 集合の例 • 自然数全体の集合(ℕ)、整数全体の集合(ℤ)、有理数全体の集合 (ℚ)、実数全体の集合(ℝ)、複素数全体の集合(ℂ) • 当社社員全員からなる集合 14 集合
  16. 元(または要素) • 集合に含まれるものを元(または要素)という • 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
  17. 16 概念モデルの第一歩→概念・集合をクラスで表す 顧客 田原さん 近藤さん 松田さん 野村さん 中森工業 小泉百貨店 河合自動車

    属性区画、操作区画 は省略可能 顧客 顧客 顧客 クラス クラス名 属性区画 操作区画
  18. 有限/無限集合 集合には元の数が有限個の有限集合と無限個の無限集合がある 単集合 1つの要素しか含まない集合を単集合という {x | 0 < x <

    2, x ∈ ℤ} = {1} ※ {1} ≠ 1 空集合 要素を1つも含まない集合を空集合という {x | 0 < x < 1, x ∈ ℤ} = {} = ∅ 有限集合/無限集合、単集合、空集合 単集合の例:当社本社 空集合の例:2乗して負数になる実数 今、たまたま空集合である場合(別 の時点では非∅)と、いついかなる ときでも空集合になるものがある 当社本社 2乗して負数になる実数
  19. 18 ドメインと概念 顧客 輸送車両 商品 受注 社員 物流拠点 自社 XXX株式会社の業務ドメイン

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

    顧客 輸送車両 受注 商品 社員 物流拠点 自社 ドメインのスコープを表す枠 =全体集合 ドメインの中にはたくさんの 要素がある それらの要素を、概念が 適用される集合へと分類 する 集合・概念をクラスで表現する
  21. 以下の業務ドメインのいずれかを対象として、情報 システム化することを目的に概念を抽出しましょう • Scrumのプロジェクト管理 • 野球の試合管理業務(試合の勝敗や選手の成績等) • マイ・ツィッター • 会社の図書管理業務

    20 演習:概念の抽出
  22. 21 属性

  23. 概念を説明するためのデータ項目を属性という 属性の例 顧客 顧客番号、顧客名、配送先住所、請求先住所、メールアドレス、生年月日、性別、好きなジャン ル、・・・ 商品 商品番号、商品名、価格、販売開始年月日、評価最高点、評価最低点、メーカー名、販売 店、・・・ 注文 注文番号、注文年月日、注文者番号、注文商品番号、使用クーポン番号、配送オプション区分、

    配送先住所、・・・ 概念が適用される個体(要素)それぞれが自分自身の属性値を持つ(属性値がな いという場合もある) リレーショナルモデルの第3正規形(あるいは、より高度の正規形)にするのは基 本だが必須ではない 22 属性
  24. - お知らせメールを希望する : 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
  25. 属性の型はプログラム言語の組み込みの型ではなく、値とし て取りうる範囲が示せる型を定める 例)属性「注文数」の型 × Integer(整数) 〇 自然数(または正の整数) これにより概念の性質がよりはっきりしてくる 以下を考えてみよう •

    数値や数字であれば、最小値、最大値が無いか • 数値や数字であれば、値の刻みが無いか • 文字列であれば桁数の最小値、最大値が無いか • 文字列であれば使用できる文字が限定されていないか • なんらかの形式を持たないか(商品番号、メールアドレス・・・) 24 属性の型
  26. 属性の中にはその値が他の属性の値から 計算されるものがある。このような属性 を派生属性という 属性名の前に/をつけて、その属性が派 生属性であることを表す 左図の派生属性 – 社員#年齢 社員#生年月日と現在年月日から計算 –

    注文#販売金額合計 紐づく注文明細の注文金額を集計 – 注文明細#注文金額 紐づく商品の単価×注文明細#注文数 条件によって派生になったり入力値に なったりすることがある。そのような場 合のモデルの表現は確立されていない 25 派生属性 - / 販売金額合計 - 注文年月日 - 注文番号 注文 - 注文品 0..* 1 - 注文明細 1..* 1 - / 注文金額 - 注文数 - 明細番号 注文明細 - / 年齢 - 生年月日 - 住所 - 氏名 - 社員番号 社員 - 受注担当社員 0..* 1 - 単価 : 日本円 - 商品番号 : 商品番号 商品
  27. 属性値をとらないのはどのような場合か • その要素は本来その属性に値をもたない • 汎化/特化を検討する(後述) • 今のところその属性の値を持っていない(いつかは持つかも) • 属性値が不明(その属性の値を持っているか否かがわからない。持っ ていたとしても値が不明)

    • 履歴データで、前の値から変わっていない(特殊) 本当はこれらを区別した値がもたれるべきだが、いずれもnull値が セットされることが多い 26 属性値をとらない可能性
  28. 属性の識別や詳細化を徐々に行っていく • 可視性は概念モデルでは基本的に不要 • 多重度はマルチバリューのときのみ • 初期値も必要なときのみで 27 属性の識別や詳細化 顧客

    お知らせメールを希望する メールアドレス[1 .. 5] 生年月日 氏名 顧客コード 顧客 お知らせメールを希望する : boolean メールアドレス[1 .. 5] : メールアドレス 生年月日 : 年月日 氏名 : 文字列 顧客コード : 顧客コード 顧客 お知らせメールを希望する : boolean = true 顧客コード : 顧客コード メールアドレス[1 .. 5] : メールアドレス 生年月日 : 年月日 氏名 : 文字列 顧客 概念を識別 属性を識別 属性の型を決める 初期値を決める 属性の初期値を決める
  29. 先の演習で抽出した以下の業務ドメインの概念に属 性を追加しましょう。必要なら概念の見直しもしま しょう • Scrumのプロジェクト管理 • 野球の試合管理業務(試合の勝敗や選手の成績等) • マイ・ツィッター •

    会社の図書管理業務 28 演習:概念の属性の抽出
  30. 29 関連

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

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

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

    結びつきを持た ない
  34. • 全体と部品 • 1つの要素をいくつかの部分に分 けたときの全体要素と部分要素の 関係 • 先行する要素と後続する要素 • 袋(入れ物)と中身

    • 同じ種類の要素どうしの対等な関 係 • ヘッダと明細 • 要素とその現在位置 • 要素とその履歴 • 要素とその所属先 • 要素とその住まい(住居・倉庫・ 設置場所や住所) • 要素と生誕地 • 要素とそれが一時的に乗ってい るもの • 要素とその役割 • 要素とその状態 • 要素とそれを説明する他の要素 など 33 結びつきのタイプ
  35. 部署 - 単価 : 日本円 - 商品番号 : 商品番号 商品

    - / 販売金額合計 : 10万未満の正整数 - 注文年月日 : 当社営業日 - 注文番号 : 注文番号 注文 - / 注文金額 : 10万未満の正整数 - 注文数 : 正整数 - 明細番号 : 正整数 注文明細 - 注文品 0..* 1 - 注文明細 1..* 1 社員 - 受注担当 0..* 1 - 部員 - 所属部署 0..* 1 - お知らせメールを希望する : boolean = true - メールアドレス[1 .. 5] : メールアドレス - 生年月日 : 年月日 - 氏名 : 文字列 - 顧客コード : 顧客コード 顧客 - 注文主 0..* 1 注文する {階層} - 子商品 - 親商品 0..* 0..1 関連はクラスとクラスの間に実線を引いて表す 関連には以下の情報を定義できる • 関連名 • 多重度 • 関連端 • 誘導可能性 • 制約 • 限定子(後述) • 集約/コンポジション(後述) 要素どうしの個々の結びつきを、関連のインス タンス、あるいはリンクという 34 UMLでの関連の表現方法 関連 多重度 関連端 関連名 誘導可能性 再帰関連 制約 集合の要素どうしの結びつきをUMLでは関連で表現する
  36. 関連名 関連につけられた名称。▶の指し先が関連の目的語にな る 関連端名 関連の相手に付けられた名称。後述の「対応」に対応す る 多重度 関連の相手としていくつの要素が対応するかを示す。属 性と同じく、多重度の最小値 ..

    最大値、または、取りう る値の数列(カンマ区切り)で表し、 最大値が無い(いくらでもよい)場合はアスタリスク (*)で表す。 • 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 {階層} 多重度 関連端 関連名
  37. 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
  38. 37 多重度の書き方 多対多(結びつきを持たない要素有) 多対多 0..* 0..* 社員 顧客 1..* 1..*

    社員 顧客 社員 顧客 社員 顧客 0..* 0以上 * 0以上 1..* 1以上 5..10 5以上10以下 1, 3, 5 1または3または5 1 丁度1 *だけでも よい
  39. たまたまある時点では、ある多重度(例えば1:多) になる場合があるとしても、別の時点で他の多重度 (例えば多対多)になる可能性がある場合は、より 数の範囲が広い方の多重度を付記すること 38 多重度の注意点

  40. 39 誘導可能性・制約・再帰関連 誘導可能性 関連の一方からもう一方を参照できるかどうかを示す 制約 関連に制約や追加の意味を付与する。制約を表すキー ワードをブレイス({ })で括って表す 例){階層}, {ordered}

    再帰関連 同一概念の要素間に関連があることを示す 例) • セット商品はいくつかの単商品から構成される • グラフ理論: 頂点は辺でつながる 線の先が矢印 矢印の反対側から矢印側を参照できる 線の先が× ×の反対側から×側を参照できない 線の先が無印 誘導可能性は未定 - 単価 : 日本円 - 商品番号 : 商品番号 商品 - / 販売金額合計 : 10万未満の正整数 - 注文年月日 : 当社営業日 - 注文番号 : 注文番号 注文 - / 注文金額 : 10万未満の正整数 - 注文数 : 正整数 - 明細番号 : 正整数 注文明細 - 注文明細 1..* 1 - 注文品 0..* 1 - お知らせメールを希望する : boolean = true - メールアドレス[1 .. 5] : メールアドレス - 生年月日 : 年月日 - 氏名 : 文字列 - 顧客コード : 顧客コード 顧客 - 注文主 0..* 1 注文する - 子商品 - 親商品 0..* 0..1 {階層} 誘導可能性 制約 再帰関連
  41. 同一集合の要素の間にリンクがある場合、その関連 を再帰関連という 40 再帰関連 駅 - 住所 - 駅名 -

    駅番号 駅 - 前駅 - 次駅 0..* 0..* 再帰関連は 該当するクラスから出て戻 る関連で表す 再帰関連の例 駅と次駅 セット商品と構成商品 組織構造
  42. 再帰関連には以下のような形態がある 階層構造(木構造)(親が高々1つ) ネットワーク構造(親が0以上) 41 再帰関連:階層構造とネットワーク構造 部1 : 組織 課1a :

    組織 課1b : 組織 係1aあ : 組織 係1aい : 組織 係1aう : 組織 係1bえ : 組織 係1bお : 組織 部2 : 組織 課2a : 組織 課2b : 組織 係2aあ : 組織 係2aい : 組織 係2bう : 組織 係2bえ : 組織 課2c : 組織 階層構造の例:組織構造 ネットワーク構造の例:路線 赤羽 : 駅 池袋 : 駅 新宿 : 駅 代々木 : 駅 原宿 : 駅 渋谷 : 駅 新大久保 : 駅 目白 : 駅 高田馬場 : 駅 大塚 : 駅 木構造の場合 ノードの数 = エッジの数-1
  43. セミナー申込 人 法人 - 申込者 1 0..* - 申込者 1

    0..* あるクラスから2つ以上の関連があり、同時にはそ のうちの1つのリンクしか持てない場合{xor}とい う制約を付記するとよい 42 XOR {xor} セミナーの申込者は、法人あるいは人のいずれかで、 同時に法人と人が申込者であることはあり得ない この多重度は、相手のリンクがな いときの多重度をつけるのがよい と考える
  44. 概念モデルでは属性と関連は同じものの表現の違いにすぎない 43 属性は関連でもある - 基本給 : 日本円 - Eメールアドレス :

    Eメールアドレス - 住所 : Address - 氏名 : String - 社員番号 : 社員番号 社員 社員 社員番号 - 社員番号 1 0..1 氏名 - 氏名 0..* 1 住所 - 住所 0..* 1 Eメールアドレス - Eメールアドレス 1 0..1 Money - 基本給 1 0..* 社員番号は共有されないの で多重度は高々1 同姓同名がいるかもしれか もしれないので多重度は 0以上 属性名は関連端名となる 属性型名はクラス名となる
  45. 型がエンティティの場合は、関連で表現 型がエンティティでない場合は、属性で表現 ただし多重度が[0..1], 1以外は関連で表現する エンティティでないものも別途どこかでモデルとして列挙す る形で描いておくとよい 44 属性と関連での表現の使い分け - 連絡先メールアドレス

    : メールアドレス文字列[1..5] - 氏名 : String - 会員番号 : 会員 会員 - 連絡先メールアドレス 1..5 1 - メールアドレス : メールアドレス文字列 メールアドレス - 氏名 : String - 会員番号 : 会員 会員 0..* 1 - 部署名 : String - 部署ID : 部署ID  部署  - 氏名 : String - 社員番号 : 社員番号  社員 
  46. 以下の業務ドメインのいずれかを対象として、情報 システム化することを目的に概念、概念の属性、概 念間の関連を抽出しましょう • Scrumのプロジェクト管理 • 野球の試合管理業務(試合の勝敗や選手の成績等) • マイ・ツィッター •

    会社の図書管理業務 45 演習:関連の抽出
  47. 以下の概念をクラスで表し、概念間の関係を関連で表現 してください。属性、多重度、関連端名もできるだけ書 きましょう ドメインは会議室予約とします 概念 • 会議室 • 会議室に設置されている備品 •

    予約(予約者(社員)1名がおり、また会議参加者(社 員)を複数名登録できる) • 社員 46 演習:概念モデルを描いてみよう
  48. 47 回答例 - 場所 - 収容人数 - 会議室名 - 会議室ID

    会議室 - 備品ID 備品 - 予約取り消し区分 - 予約年月日 - 会議室予約番号 会議室予約 - 予約対象会議室 0..* 1 - 設置備品 - 設置先会議室 0..* 0..1 - 氏名 - 社員番号 社員 - 予約者 0..* 1 - 出席者 0..* 0..* - 名称 - 備品区分コード 備品区分 0..* 1 この多重度は ・予約者以外の出席者を示す関連だ とすれば最小値0(予約者が1人で 会議室を使う場合もある) ・そうでなくて予約者も含んだ出席 者を示すとすれば最小値は1 ・もっと言えば、予約者が出席する とは限らない(予約だけする人)の で、そう考えたら最小値は1にすべ き ・でも、ちょっと待てよ。先に会議 室だけとって、あとから参加者を決 める、というのもあるか。そういう 意味では参加者の設定はしてもしな くてもよい、とすべきか・・・
  49. 制約とは、UMLの記号に追加の意味を表現するため の記号 • 制約はブレイス{ }で囲んで表示する 例){ordered}, {階層} • 1つの関連に複数の制約を指定したい場合は、ブレイ ス内にカンマで区切って並記する

    例){制約1, 制約2} • 制約は関連だけでなくいろいろなものに付けることが できる 48 制約
  50. {階層}は、組織の上位・下位の関係がツリー構造になっ ていることを表す 49 関連の代表的な制約 {階層} 組織 {階層} - 下位組織 -

    上位組織 0..* 0..1 制約 階層 部1 : 組織 課1a : 組織 課1b : 組織 係1aあ : 組織 係1aい : 組織 係1aう : 組織 係1bえ : 組織 係1bお : 組織 部2 : 組織 課2a : 組織 課2b : 組織 係2aあ : 組織 係2aい : 組織 係2bう : 組織 係2bえ : 組織 課2c : 組織 こちらの多重度は必ず0..1 ※無限を考えない場合 こちらの多重度の最小値は必ず0 無限を考えない場合
  51. 50 {階層}では以下は許されない 部1 : 組織 課1a : 組織 課1b :

    組織 係1aあ : 組織 係1aい : 組織 係1aう : 組織 係1bえ : 組織 係1bお : 組織 部2 : 組織 課2a : 組織 課2b : 組織 係2aあ : 組織 係2aい : 組織 係2bう : 組織 係2bえ : 組織 課2c : 組織 このリンクは許されない ツリー構造ではない 下位組織 上位組織
  52. {階層}は ツリー構造であることを 指定しているだけ 左記のような構造も許さ れる これを許さないためには 別の方法が必要 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 : 組織 部の下に課をはさまずに係 た直接ついている 係の下に課がつく
  53. リンクしている要素に順序がある。 つまりリスト(いったんそう考えるが、そうならない場合も。後ほど再考) 例)渋41[東急バス]の路線 [渋谷駅, 道玄坂上, 大坂上, 大橋, 菅刈小校, ・・・] 52

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

    unique} 関連の代表的な制約{ordered} 路線 停留所 ① ② ③ ④ ① ② ④ ③ 路線X 路線Y 路線 停留所 路線X ① ② ③ ④ ⑤ ⑥ ⑦
  55. 以下はリストにならないケース 同一順序がある、というのを許すか 半順序(順序づけできないものどうしがある)を許すか 54 関連の代表的な制約{ordered}

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

    同じ概念間の複数の関連 受注 商品 注文品としてのリンク 試供品としてのリンク 55 - 注文品 1 0..* - 試供品 0..1 0..* 商品 受注 - 到着駅 1 0..* - 解散駅 1 0..* - 出発駅 0..* 1 駅 旅行
  57. 次に関連クラスおよび限定子を説明します その前提知識としてまず直積と関係について少し学 んでいただきます 56 関連クラスと限定子

  58. 集合Aの任意の元aと集合Bの任意の元bとの順序づ けられた組(a, b)の全体からなる集合をAとBとの 直積といいA×Bと書く A×B={(a, b)| a ∈A, b ∈

    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が成り立つ」というような言い方をする
  59. 集合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=∅
  60. 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 演習:直積 答え
  61. 概念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 関係(集合論での)
  62. • 関連が属性や、他への関連を持つ場合がある • それを示すには、関連をクラスとして表現し、属性をもたせたり、他クラス への関連線を引く • 関連をクラスとして表現したものを関連クラスという • 「社員」と「組織」の間の関連「所属」には、配属年月日という属性を持つ •

    「エンジニア」と「プロジェクト」の間の関連「参画」は、「ロール」という概念へ の関連を持つ ※関連クラスは前スライドで説明した関係のグラフとみなすことができる 61 関連クラス 参画 1..* 0..* ロール 0..* 0..* プロジェクト エンジニア 1 0..* - 配属年月日 所属 組織 社員 関連クラス 関連クラスは、関連 線から点線でつなが るクラスで表す 関連クラスが属性を 持つ場合、通常のク ラスと同様に表す 関連クラス 関連クラスが他のク ラスと関連を持つこ とがある
  63. 62 関連クラスのイメージ aさん 営業部 (a,営業部) 社員 組織 bさん 開発部 経理部

    cさん dさん (b,開発部) (c,開発部) (d,経理部) 関連クラス:所属関係Rのグラフ 1 0..* - 配属年月日 所属 組織 社員 社員×組織(直積)に属する以下の組(要素) は上のRのグラフ(集合)には含まれない ※社員と組織の間にリンクがないから (a, 開発部), (a, 経理部), (b, 営業部), (b, 経理部), (c, 営業部), (c, 経理部), (d, 営業部), (d, 開発部)
  64. 0..* 0..* プロジェクト 参画プロジェクト : プロジェクト 0..* ロール エンジニア 参画

    1..* 0..* ロール 0..* 0..* プロジェクト エンジニア 関連クラスによって表現されたモデルは、限定子という 別の方法を使って表すことができる 63 関連クラスを別の方法で表す 限定子 限定子 参画プロジェクト:プロジェクト 限定子名 型 省略可 左のモデル エンジニアとプロジェクトには参画という関連があり、参画に対してあるロールを担っている 右のモデル エンジニアが参画プロジェクト毎の自分のロールを知っている これを「参画」にしてもよい。その場 合は多重度が0..1 多重度の最小値は0にな る(参画していないプロ ジェクトに対するロール はないため) 必要なければ限定子の型を表 す概念を図に描かなくてよい (限定子の型はStringやDate の場合もある)
  65. 3つ以上の概念間の関連を引くことができる。UMLではこれをn項関連(nは関連に関わる概念 の数)という 例) 社会人向け外国語学習塾があり、6か国(英語、中国語、韓国語、フランス語、ドイツ語、ロ シア語)を学ぶことができる。受講時間帯は月~金の19時~20時と固定であり、どの日も全 ての外国語の授業を行っている。生徒は曜日毎に学びたい外国語を選択できるが、どの曜日に どの外国語を学ぶかを事前に登録しておく これを生徒AがX曜日にYという外国語を受講する、として以下の3項関連のモデルで表現する n項関連も、関連が属性をもったり、関連を持つ場合は、2項関連と同様、関連クラスでそれを 表現することができる

    64 n項関連 曜日 外国語 生徒 1..* 1..5 1..6 受講する
  66. n項関連も、関連が属性や関連を持つ場合は、2項関連と 同様、関連クラスでそれを表現することができる また関連クラスを限定子を使って表現することもできる 65 n項関連の関連クラス、限定子 曜日 外国語 生徒 1..* 1..5

    1..6 受講する - 出席日数 - 開始年月日 学習状況 曜日 外国語 生徒 1..* 1..5 1..6 関連クラス 受講外国 : 外国語 受講曜日 : 曜日 0..1 - 出席日数 : int - 開始年月日 : int  学習状況  生徒 受講曜日:曜日 受講外国語:外国語 限定子 n項関連の場合はn-1個の 限定子名が列挙される 関連クラス 限定子
  67. UMLでは全体を表す要素と部分を表す要素が紐づくことを表す関連 として、集約(Aggregation)、とコンポジションという関連が 用意されている 66 集約/コンポジション 会社 社員 部署 0..* 1

    0..* 1 集約 白いダイヤモンド コンポジション 黒いダイヤモンド 会社全体は社員から構成さ れている 会社全体は部署から構成されてい る 全体 部分 部分
  68. 集約とコンポジションはどちらも全体 – 部分の関係を表す 制約的には集約よりコンポジションのほうが強い。コンポジションには特に以下 の制約が課される • 部分の要素に紐づく全体の要素はちょうど1つ(0でもなければ2以上でもない) • 全体側について、同一概念の要素が1つになるのはもちろん、異なる概念が全体になる場 合でも、1つの概念の1つの要素の部分になる

    • 全体の要素が削除されたら、それにリンクする部分側の要素も削除される しかし、集約やコンポジションと通常の関連の差はあいまいで、人により様々な 意味合いを持って使われている。Martin Fowler氏は著作「UML Distilled」の 中で集約は使わないことを推奨している 67 集約とコンポジションの違い 顧客 氏名 1 社員 1
  69. 1つの要素をいくつかの構成要素に分割するとき → コンポジションを使う 属性を関連で表すとき → 集約を使う その他 → 通常の関連を使う 68

    集約/コンポジション/関連 どう使い分ける
  70. 集約はコンポジションより制約がゆるい。 コンポジションに要求される以下の制約は、集約では要求されない • 部分の要素に紐づく全体の要素はちょうど1つ(0でもなければ2以上でも ない) • 全体の要素が削除されたら、それにリンクする部分の要素も削除される 値がユニークであるかそうでないかを多重度で表す 69 関連で表した属性は集約で表す

    会員 住所 1 0..* メールアドレス 0..5 0..1 同一住所を持つ会員が複数いる場合がある (家族 等) メールアドレスはユニークでなければならな い
  71. 属性と同じく、関連にも派生がある 合成 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では関連名の前に/を付記して派生であること を示す
  72. 導出 属性や他の関連等から、なんらかの計算を行って求められる関連 例)シーザー暗号化された文字列から、候補となる鍵(ずらした分 の文字数)への関連 71 派生関連(導出) この関連は、アルファベットからなる暗号化された文字列と、アルファベット 26文字の一般的な頻出割合を用いることで推測できる G Hutton,

    Programming in Haskell Second Edition. CAMBRIDGE UNIVERSITY PRESS を参照 - アルファベットからなる暗号化された文字列 シーザー暗号により暗号化された文字列 0から25までの整数 - 候補鍵 1 0..* アルファベットの頻度リスト 有理数 アルファベット : アルファベット 1 アルファベット文字列の各文字を 正の方向へ0~25文字数だけずら す暗号化の手法。ずらす文字数を 鍵という。 例) HAL → IBM(鍵=1) ※派生属性や派生関連は操作区画に操作として書かれることもある
  73. 72 スーパタイプ/サブタイプ

  74. 集合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
  75. 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
  76. 75 部分集合はスーパタイプ/サブタイプで表す 会員 偶数 ゴールド会員 偶数 5の倍数 偶数かつ5の倍数 5の倍数 偶数

    5の倍数 偶数 5の倍数 会員 ゴールド会員 特化 汎化 包含する側の概念 スーパータイプ 包含される側の概念 サブタイプ
  77. サブタイプはスーパタイプの属性や関連を持つ。これを 属性・関連の継承という • スーパタイプに属する要素は、同時にスーパタイプに属 する要素でもあるから • ゴールド会員であるAさんは、会員である • 男性であるBさんは、人間である •

    概念モデルでは継承は、属性やメソッドの再利用として 考えるのではない 76 属性・関連の継承 A a b c サブタイプの 要素は A a b c スーパタイプの 要素でもある
  78. • サブタイプがさらにサブタイプを包含する場合がある • この系列は何段階続いてもよい 77 サブタイプのサブタイプ A ⊃ A’ ⊃

    A’’ ⊃ ・・・ 例) • 哺乳類 ⊃ 獣亜綱 ⊃ 有胎盤類 ⊃ 北方真獣類 ⊃ 真主齧類 ⊃ 霊長目 ⊃ ヒト • 複素数 ⊃ 実数 ⊃ 有理数 ⊃ 整数 ⊃ 自然数 自然数 整数 実数 有理数 複素数
  79. 集合系 • 元が全て集合である集合を集合系という ※上の意味での集合を集合族と呼ぶ著書もあるが、当講義では、集合族とはあ る添字集合から上の意味での集合系への写像のこととし、集合系と集合族を区 別する • 例)東京に本社がある株式会社の社員の集合の集合 78 集合系

    東京に本社がある株式会社の社員の集合の集合 A社の社員の集合 A社の社員の集合 B社の社員の集合 B社の社員の集合 集合系
  80. 巾(べき)集合 • 集合Aの部分集合全体からなる集合系をAの巾(べき)集合とい う • 例)A={a, b, c}のべき集合 {∅, {a},

    {b}, {c}, {a, b}, {a, c}, {b, c}, {a, b, c}} ※べき集合の要素数は2の元集合の要素数乗 • 集合Aの巾集合を (A) 、 (A)、2A などと書く • 巾集合は英語ではpower setという 79 巾(べき)集合 (A) A Aの巾集合
  81. 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の部分集合系
  82. 集合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の直和分割 ではない(②を 満たさない)
  83. 集合「人」に対して ① 「性別が女性」、「性別が男性」、のみを要素とする、「人」 の部分集合系Xは、「人」の直和分割である ② 「国籍が日本」、「国籍がアメリカ」、「国籍が中国」、「国 籍がこれら以外」、のみを要素とする、「人」の部分集合系Y は、「人」の直和分割である ③ ①の直和分割に、②の任意の要素を加えたものは、直和分割

    ではない(逆もしかり) 集合はいくつかの直和分割を持つ 女性 男性 人 人の性別による直和分割 日本 U.S.A 中国 人 人の国籍による直和分割 女性 男性 人 人の直和分割ではない部分集合系 82 日本
  84. 制約 disjoint で表す その他があるかないかを以下の制約で表す その他有 complete その他無 incomplete 83 直和分割のクラス図表現

    人 日本人 アメリカ人 中国人 {disjoint, incomplete} 人 男性 女性 {disjoint, complete}
  85. • 概念Aに対して2つ以上の直和分割を定めるとき、 Aは多重分類されているという 84 多重分類 人 男性 女性 日本人 {disjoint,

    complete} :性別 :国籍 アメリカ人 中国人 {disjoint, incomplete} {incomplete} :社会人 社会人 {incomplete} :学生 学生 矢頭を共有しているサブタイプ は、同じ直和分割の要素どうし である 直和分割につけられた名前。コロン の後に続けて書く。これを パワータイプ(後述)の名前という disjoint / overlapping incomplete /complete
  86. 物事を分類・整理したい • 概要から詳細へ • 一般から個別へ • 抽象から具体へ スーパタイプからサブタイプ への特化となる サブタイプ側で新たな属性や

    関連が順次追加される 85 特化を引き起こす動機 哺乳類 獣亜綱 単孔類 有胎盤類 有袋類 アフリカ獣類 異節類 北方真獣類 真主齧類 ローラシア獣類 霊長目 齧歯目 ウサギ目 ヒヨケザル目 ツパイ目 ヒト 特化
  87. 別の概念を区別せずに見るときがある 例)パーティパターン:人と組織は別の概念だが、連絡帳にのせるときはどちら も区別せず、名前、メールアドレス、電話番号を記録する 汎化する前にサブタイプがそれぞれもっていた同種の属性を、汎化したあとに スーパタイプに持たせる 86 汎化を引き起こす動機 1 - 電話番号

    - メールアドレス - 氏名 人 - 代表電話番号 - 代表メールアドレス - 組織名 組織 人 組織 パーティ 人 組織 人 組織 - 連絡用電話番号 - 連絡用メールアドレス - 名称 パーティ(人/組織) アドレス帳 0..* - 電話番号 - メールアドレス - 氏名 人 - 代表電話番号 - 代表メールアドレス - 組織名 組織 パーティ(人/組織) 連絡帳 0..* アドレス帳 アドレス帳
  88. 異なる概念が共通部分を持っている ※異なる集合に属する要素が存在する。それらを重複してもたず1要素として管理したい 例)A病院では医師と患者(患者カードを発行されている人)を別に台帳管理していたが、 医師の中にも当病院で受診し患者カードを発行された者がいて住所や氏名などが2重管理 されていた 汎化する前にサブタイプがそれぞれもっていた同種の属性を、汎化したあとにスーパタイ プに持たせる 87 汎化を引き起こす動機 2

    - 住所 - 専門 - 生年月日 - 氏名 - 医師ID 医師 - 住所 - 生年月日 - 氏名 - 患者番号 患者 - 住所 - 専門 - 生年月日 - 氏名 - 医師ID 医師 - 住所 - 生年月日 - 氏名 - 患者番号 患者 患者としても登録されている医師 - 専門 - 医師ID 医師 - 患者番号 患者 - 住所 - 生年月日 - 氏名 - 人材ID 病院人材 医師 患者 医師 患者 医師 患者 病院人材
  89. 直和分割による分類では、静的分類(要素は同じ1つの部分集合の要素であり続 ける)としてモデル化されることが多い しかしUMLでは、要素が直和分割の部分集合を移動することをモデルとして表現 できる こうした直和分割による分類を表現したものを動的分類という 例)商品は「販売予定商品」の要素から始まり、「販売中商品」の要素として市 場に売り出され、販売終了により「販売終了商品」の要素になる 88 動的分類 -

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

    商品 商品販売状態 1 1 - 販売予定単価 - 販売商品仮名 - 販売開始予定年月日 商品販売状態‐販売予定 - 販売単価 - 販売商品名 商品販売状態‐販売中 - 販売終了年月日 商品販売状態‐販売終了 商品販売状態 販売予定商品 販売中商品 販売終了商品 商品
  91. 以下のケースでも実は動的分類がある 90 動的分類をもう少し 医師 患者 病院人材 病院人材 医師 患者 医師

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

    役割の帽子 医師(という役割/帽子) 病院人材 病院人材 医師 0..1 1 患者 0..1 1 91 患者(という役割/帽子)
  93. インスタンス(要素)が他のオブジェクト型(概念)のサブタイプ であるようなオブジェクト型(概念) 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 * パワータイプ 以下の要素が属する 生命保険 医療保険 損害保険 コロンに続けてパワータイプ の型名を書く。これによりサ ブタイプとパワータイプが結 びつく パワータイプの使いどころ サブタイプに属する個々の要素が持つ属性や関連とは別に、サブタイプそのもの が持つ属性や関連がある場合にパワータイプの属性や関連としてそれらを表す
  94. 概念としての解釈 概念モデルとしては、パワータイプの要素とサブタイプは同じものを二重に表現したものである。 よって、サブタイプのいずれかをモデルから削除したときには、対応するパワータイプの要素も同時 に削除されたものとみなす 多重分類がある場合、パワータイプは複数になる場合がある サブタイプがさらにサブタイプを持つ場合、パワータイプにその階層を表す関連が持たれる 93 パワータイプ 保険証券 損害保険

    医療保険 生命保険 {disjoint, incomplete} : 保険の種類 保険の種類 1 * 保険カバレージタイプ 終身保険 自動車保険 火災保険 地震保険 団体保険 個人保険 {disjoint, complete} : 保険カバレージタイプ 1 * - サブタイプ - スーパタイプ 0..* 0..1
  95. 対応:A → Bに対して、Aの部分集合であるA‘に対 して対応:A’ → B を考えたとき、この対応をの A’への制限といい、|A’と書く。写像についても同 様 94

    対応/写像(関連)の制限 対応の制限 A A‘ B B‘ A A‘ B B‘
  96. 会員 購入 - 購入 - 購入者 0..* 1 有料会員 獲得ポイント数

    : int 有料会員購入 - 購入|有料会員 - 購入者|有料会員購入 0..* 1 会員 購入 - 購入 - 購入者 0..* 1 有料会員 獲得ポイント数 : int 有料会員購入 - 購入|有料会員 - 購入者|有料会員購入 0..* 1 対応/写像先も部分集合になることを明示する 対応/写像の制限はどういう時に使うか1 会員 有料会員 購入 有料会員購入 会員 有料会員 購入 有料会員購入 対応の制限 このリンクが許され ることになる 対応の制限 こちらに対応の制限 を指定しないと
  97. 多重度が変わる(狭くなる) 96 対応/写像の制限はどういう時に使うか2 プロジェクト ロール エンジニア PG SE PL PL

    PG SE PLはプロジェクト毎 に必ず一人 プロジェクト ロール 0..* 1 プロジェクトリーダ エンジニア - 参画 0..* 0..* - Γ|プロジェクトリーダ 1 0..* 多重度が0..*から1に 変わった 対応の制限で多重度を変えるときは、制限されないときの多重度よ り範囲を広げてはならない。狭くなるようにすること
  98. 対応/写像の制限はUMLでは関連の制約である {redefines}で表現する 表記 {redefines スーパタイプ側の関連端名} 97 対応/写像の制限のUMLでの表記 会員 購入 -

    購入 - 購入者 0..* 1 有料会員 獲得ポイント数 : int 有料会員購入 {redefines 購入者} {redefines 購入} 会員 有料会員 購入 有料会員購入 会員 有料会員 購入 有料会員購入 このリンクが許され ることになる この制約をつけるかつけな いかでモデルの意味が変わ る。2つ前のスライドのベ ン図を参照のこと
  99. リンクの一部に特別な意味がある場合、制約{subsets}でそれを表す 表記 {subsets 特別な意味が含まれる関連端名} 下のモデルでは以下が表されている 上の関連 チームには複数の選手が所属する 真ん中の関連 所属している選手の一部はレギュラーである 下の関連

    所属している選手のうち1名がキャプテンである 98 subsets 選手 チーム - 所属 1 0..* {subsets 所属} - レギュラー 1 0..* {subsets 所属} - キャプテン 1 0..1 選手 全てのリンクは所属 赤いリンクはレギュラー 点線のリンクはキャプテン チーム
  100. 99 変化

  101. - 消費税 - / 注文金額合計 - 注文年月日 - 注文番号 注文

    - / 注文金額 - 注文個数 - 注文枝番 - 注文番号 注文明細 1..* - 商品名 - 商品単価 - 商品番号 商品 - 注文品 0..* 1 よくあるモデル 100 商品単価が変わったら 注文金額 = 注文品.商品単価 * 注文個数 でも注文の半年後に商品単価が改訂 されたら、半年前の注文の注文金額 はわからなくなる
  102. 履歴で表す。大きくは以下の3パターン(か?) 101 履歴 1. 商品と同じ項目を履歴に持たせる 2. 変わった項目のみ履歴に持たせる 3. 商品と同じ項目を持つ履歴に対して 関連が引かれる

    - 消費税 - / 注文金額合計 - 注文年月日 - 注文番号 注文 - 商品履歴番号 - / 注文金額 - 注文個数 - 注文枝番 - 注文番号 注文明細 1..* - 商品名 - 商品単価 - 商品番号 商品 - 注文品 0..* 1 - 商品単価 - 商品名 - 商品履歴番号 - 商品番号 商品履歴 0..* - 消費税 - / 注文金額合計 - 注文年月日 - 注文番号 注文 - 商品履歴番号 - / 注文金額 - 注文個数 - 注文枝番 - 注文番号 注文明細 1..* - 商品名 - 商品単価 - 商品番号 商品 - 注文品 0..* 1 0..* - 変更値 - 変更項目 - 商品履歴番号 - 商品番号  商品履歴  - 消費税 - / 注文金額合計 - 注文年月日 - 注文番号 注文 - / 注文金額 - 注文個数 - 注文枝番 - 注文番号 注文明細 1..* - 商品名 - 商品単価 - 商品番号 商品 - 注文品 0..* 1 - 商品単価 - 商品名 - 商品履歴番号 - 商品番号 商品履歴 0..* 商品履歴番号が必要 商品履歴番号が必要
  103. 履歴 バイテンポラルデータモデル ファウラーのパターン イベントソーシング 102 概念モデルを脅かすもの・・・それは時間

  104. 103 メタファー

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

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

    105 XPのメタファー代表例
  107. 106 実践

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

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

  110. 109 PLAN – DB THモデル

  111. • 経営資源を表す概念 • 社内組織(事業部、部、課、社員、協力会社、その分類の性別、資格など) • 社外組織(顧客、卸、銀行、その分類の業種、地域など) • 設備(工場、建機、金型、事務所など) • 品役(商品、資材、サービス、その分類など)

    • 金(資本金、借入金、勘定科目など) • その他 • 上記のような概念を以下の3つの視点で分類して抽出する • オカレンスリソース • 経営資源そのものを表す。一般的に識別番号を持つ • タイプリソース • 経営資源の分類観点 • リソース関連 • リソース間の関連を表す • 要素のライフサイクルは一般的に長く、その間で属性値や関連が更新される ことがある • イベントの4W1Hの指し先として機能する(主にオカレンスリソース) • 共用度が高 110 THモデル:リソース
  112. • ビジネス遂行中に発生した出来事(事実/Fact)を表す概念 • 以下の3つに分類できる • 通常イベント • 発生タイミングが定まっていないもの • 受注、出荷、請求、入金、生産指図、出勤、機器故障

    など • 定時イベント • 発生タイミングに周期性があるもの • 給与支払い、月次売上報告 など • 異動イベント • オカレンスリソースや関連リソースの生成/消滅/属性値変更/関連変更を起動するイベント • 採用 → 社員 • 購入 → 固定資産 • 所属移動 → 所属(部署と社員の間の関連リソース) • 昇進 → 社員の役職(属性) • 契約金額増額 → 契約の金額(属性) • 要素のライフサイクルはリソースに比べて短く、入力ミス等特殊な場合を除いて属性や関 連は更新されない • 属性としては4W1H(What、Who/Whom、Where、When、How much)を持つ のが一般的。これらの指し先はリソースとなる • 共用度が低 111 THモデル:イベント
  113. • 在庫 • イベントにより常時変化する在庫数や残高を管理しているものを概念として把 握したもの • 商品在庫、預金残高 など • 断面

    • リソースや在庫のある時点(年末、4半期末、月末、週末、日末など)の状態 の記録を概念として把握したもの • 月末商品在庫、商品履歴、貸借対照表 • 要約 • 通常イベント、定時イベントの主に数値属性のある期間の要約の記録を概念と して把握したもの • 四半期別商品別売上実績、月次社員別稼働実績、損益計算書 • 要約のキーは期間に加えて、他のオカレンスリソース(部署、社員、顧客な ど)が用いられる場合がある • 要約されるデータは合計、平均、最大、最小、中央値、最頻値、最近値など 112 THモデル:在庫、断面、サマリー
  114. 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 異動イベント タイプリソース オカレンスリソース リソース関連 地域と商品によって出荷する倉庫が 決まるというビジネスルールを表し ている
  115. 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 通常イベント 在庫 断面 要約
  116. • 本日は割愛 • 2つのクラスの協調に関するパ ターンとして12種類のパターン を定義 • これらパターンの紹介と、協調 のルールや98個のモデリングの 原則をまとめている

    115 ストリームラインドオブジェクトモデリング
  117. カテゴリとパターンプレイヤ 116 ストリームラインドオブジェクトモデリング カテゴリ パターンプレイヤ 人 アクタ ロール 場所 場所

    外部の場所 モノ 品目 特定品目 組立品 部品 コンテナ コンテンツ グループ メンバ 事象 トランザクション コンポジットトランザクション 明細 後続トランザクション
  118. # 名称 説明 原則 11 人の原則 システムに関与しているそれぞれの人をモデリングする際には、アクタオブジェク トを使用します。同様に、1つのエンティティのようにシステムに関与している 人々の組織をモデリングする際にも、アクタオブジェクトを使用します。 原則

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

    17 事象の原則 ある場所で1つのモノと相互作用する人の事象は、トランザクションオブジェクト としてモデリングします。ある時点での相互作用は、1つのタイムスタンプを持つ トランザクションとしてモデリングします。期間の事象は、複数のタイムスタンプ を持つオブジェクトとしてモデリングします。 原則 18 履歴の原則 人、場所、モノについての履歴的、または時間に重要な意味がある事象の情報を記 録するには、期間を持ったトランザクションを使用します。 原則 19 コンポジット事象の 原則 ある場所で複数のモノと相互作用する人は、コンポジットトランザクションとして モデリングします。関与するモノごとに、特定の相互作用の詳細を獲得するために、 明細を含めます。 原則 20 後続事象の原則 前の事象に後続し事象に依存した事象は、後続トランザクションでモデリングしま す。 118 オブジェクトの識別に関する原則 1/2
  120. 協調パターン 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
  121. 120 アクタ - ロール 人 顧客 0..1 1 従業員 0..1

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

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

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

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

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

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

    0..* 0..* 1 販売担当者 0..1 1 0..* 1 126 トランザクション - ロール アクタ ロール トランザクション 事象に関わるものを記録するために使用する • トランザクションは、1つのロール、つまりその相互作用の実行者を知ってい る • ロールは、ゼロ個以上のトランザクションを知っている。ロールは、トランザ クションに関与する人、組織、モノ、あるいは場所のコンテキスト上の記述を 提供する トランザクション ロール 0..* 1 トランザクション 場所 0..* 1 トランザクション 特定品目 0..* 1 ロール ロール トランザクション
  128. 配送物 製造工場の倉庫 搬入場所 1..* 1 0..* 1 127 トランザクション -

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

    128 トランザクション - 特定品目 トランザクション ロール 特定品目 品目 1つのモノに関わる事象を記録するために使用する • トランザクションは、1つの特定品目を知っている • 特定品目は、1つ以上のトランザクションへ関与させることができる。トラン ザクションは、複数の相互作用について特定品目の履歴を記録する コンポジットトランザクション トランザクション ロール 0..* 1 トランザクション 場所 0..* 1 トランザクション 特定品目 0..* 1 明細 1..* 1 特定品目 明細 0..* 1
  130. コンテンツ製造者 タイトルライセンス条項 タイトル条項 1..* 1 コンテンツタイトル 0..* 1 0..* 1

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

    明細 コンポジットトランザクション 特定品目 明細 コンポジットトランザクション 0..* 1 トランザクション 特定品目 0..* 1 明細 1..* 1 特定品目 明細 0..* 1 トランザクション 後続トランザクション 0..* 1 複数のモノに関わる事象におけるモノの特定の関わりを記録するために使 用する • 特定品目は、ゼロ個以上の明細に関わることができる • 1つの明細は、1つの特定品目を正確に知っている。1つの明細は、特定品目 のコンポジットトランザクションとの相互作用についての詳細を取り込む
  132. 直前の事象の後にだけ発生する事象を記録するために使用する • トランザクションは、いくつかの後続トランザクションを知っている • 後続トランザクションは、正確に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
  133. • 本日は割愛 • 概念モデリングのパターン集 • 主にモデルに柔軟性を持たせるた めのパターンが取り上げられてい る • パターンは段階的に少しずつ変化

    に強くなる流れで説明されている • 過度に適用しないこと。柔軟性が 求められることが最初からわかっ ているところや、そうでないとこ ろで後日弾丸が撃ち込まれたとこ ろ(後述)にアナリシスパターン を適用するのがよい 132 アナリシスパターン
  134. アロマコーヒーメーカーズ(ACM)社は、事業部、地域、部門、営 業所という組織階層からなっていた これを単純にモデル化すると以下のようになる 133 組織階層 しかし、ある日のこと、CEOから、不確実性が高く変化に対 して迅速に対応することが求められる現ビジネス環境におい て、組織構造は常に変更できるようにしたい(例えば地域を 廃止してよりフラットにするなど)とのニーズが出された 事業部

    地域 部門 営業所 0..* 1 0..* 1 0..* 1
  135. 最初の変更 • 地域を廃止しても、地域を表すサブタイプを削除し、要素レべ ルでリンクをつけかえれば対応できる • モデルの変更は必要ない 134 組織階層 組織 事業部

    地域 部門 営業所 0..* 0..1 またしてもCEOから、組織階層はこれまでの製品による組織階層だけではなく、 それは維持しつつも、市場に対する新たな組織階層も設けることとし、各組織単 位はこの両方の組織階層の中に構成されるとの指示が出された
  136. 次の変更 • 組織階層を表す関連を増やした 135 組織階層 組織 事業部 地域 部門 営業所

    0..* 0..1 0..* 0..1 製品の組織 階層 市場の組織 階層 しかしCEOは、今後も必要であれば、第三、第四の組織階層を設け ていきたいとの希望を表明した そのたびに関連線を追加(モデルの変更)するのか
  137. 次の変更 • 組織構造は親組織・子組織・組織構造型の3項関連クラスである • このモデルだと新しい階層関係を増やす場合は組織構造型のインスタンスを追 加し、そのインスタンスと親組織、子組織の3項のリンクを追加するだけで対 応できる(モデルの変更は不要) 136 組織構造 組織構造

    組織 事業部 地域 部門 営業所 組織構造型
  138. アナリシスパターンを用いるときの戦略 • 不要な柔軟性は排除する(YAGNI) • しかし一度変更を要求された箇所については、今後変 更が求められときに迅速に対応できるよう備えておく We take the first

    bullet, and then we make sure we are protected from any more bullets coming from that gun. • そのような箇所にアナリシスパターンを適用する 137 段階的に柔軟性を高めていく
  139. ご清聴ありがとうございました 138

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

  141. 対応 • A, Bを2つの集合とし、ある規則Γ(ガンマと読む)によって、Aの 各元aに対してそれぞれ1つずつBの部分集合Γ(a)が定められている とき、その規則ΓのことをAからBへの対応という • ΓがAからBへの対応であることを Γ:A→Bと表す •

    Bの部分集合Γ(a)を、 Γによるaの像という Γ(a)は∅でも、Bと等しくてもよい 対応 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)
  142. 写像 • 対応の特別なケース。任意のa∈Aに対してΓ (a)の要素数が1であるとき、 その対応を写像という • 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)
  143. 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 多重度が1のときは 写像
  144. Γ: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
  145. 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)が∅
  146. Γ: 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)が単集合でない
  147. 大きくは次の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 多 対 多
  148. 集合の要素が集合である、というのも数学的には許されている 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
  149. 写像を関数と呼び変えて、対応も写像(関数)とみなす ことで、概念間の関連は関数とみることができる 148 写像は関数 所属先部署 :: 社員 -> 部署 所属社員

    :: 部署 -> [社員] 社員番号 :: 社員 -> 社員番号 氏名 :: 社員 -> String 住所 :: 社員 -> Address Eメールアドレス :: 社員 -> Eメールアドレス 基本給 :: 社員 -> 日本円 部長 :: 部署 -> 社員 管理先部署 :: 社員 -> 部署 - 基本給 : 日本円 - Eメールアドレス : Eメールアドレス - 住所 : Address - 氏名 : String - 社員番号 : 社員番号 社員 - 部署名 : int 部署 - 所属先部署 - 所属社員 1 1..* - 部長 - 管理先部署 1 0..1 Haskell風に書いてみた 関連は、データベースのキーと外部キーの関係だけでなく、関数と してロジックでアウトプットされるものも含まれる 関数名 関数の始域: クラス名 関数の終域: クラス名 属性名や関連端名が 関数名になる []はリストを 表す
  150. 集合Aの任意の元aと集合Bの任意の元bとの順序づ けられた組(a, b)の全体からなる集合をAとBとの 直積といいA×Bと書く A×B={(a, b)| a ∈A, b ∈

    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が成り立つ」というような言い方をする
  151. 集合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=∅
  152. 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 演習:直積 答え
  153. 対応のグラフ、写像のグラフΓ 対応 Γ :A → Bのグラフとは直積A×Bの部分集合 G(Γ)={(a, b) ∈A×B| b

    ∈ Γ(a)} 写像 f:A→ Bのグラフも直積A×Bの部分集合 G(f)={(a, b) ∈A×B| b = f(a)} 152 対応/写像のグラフ 152 1 2 a b c (1, a) (1, b) (2, c) 対応ΓのグラフG(Γ)⊂A×B A B 3 1 2 a b c (1, a) (3, a) (2, c) 写像fのグラフG(f)⊂A×B A B 3
  154. 社員 プロジェクト - プロジェクトメンバー - 参画プロジェクト 0..* 0..* - 参画期間

    : 期間 プロジェクト参画 ロール - プロジェクトでの役割 1..* 0..* 関連クラスはいつ必要か 対応/写像のグラフが属性/関連を持つとき • プロジェクト参画は参画期間という属性を持つ • プロジェクト参画はロールと関連を持つ i.e. 対応、写像のグラフが、対応/写像の始域となるとき プロジェクトでの役割: プロジェクト参画 → ロール 参画期間 : プロジェクト参画 → 期間 153 対応/写像のグラフは関連クラスで表す 関連クラス 関連線に点線で つながる
  155. リストは自然数から対象への写像(部分関数)であ る 路線のリスト : ℕ → 停留所 0→渋谷駅, 1→ 道玄坂上,

    2→大阪上 リストのことを点列ともいう(対称が数値なら数列) 154 リストの数学表現
  156. これ以降没スライドです 155 没スライド

  157. 識別子(IDやPK)で管理されないオブジェクト 例 • 住所(郵便番号×都道府県×市区町村×丁目番地×建物) • 量(数値×単位) 値オブジェクトの特徴 • そのドメイン内の何かの計測結果や説明のための値である •

    状態は不変(イミュータブル, immutable)。更新できない。何か の属性値を変えるときには、値オブジェクトを置き換える • 関連する属性を不可欠な単位として組み合わせることで、概念的な統 一体を形成する • 等しいかどうかは値の等しさでチェックする/できる IDDD本では値オブジェクトをできる限り使うことを推奨している 156 値オブジェクト(まず教科書的な説明)
  158. 何が値オブジェクトか • プリミティブ(言語組み込み)なデータ型 Integer, String, Date, ・・・ • プリミティブなデータ型の取りうる値を制限したり、なんからの形式 を持たせたもの

    0以上のInteger, メールアドレス, 年月 • 関連する属性を不可欠な単位として組み合わせることで、概念的な統 一体を形成するもの 住所(郵便番号×都道府県×市区町村×丁目番地×建物) 量(数値×単位) 本質は • IDで管理する必要のないもの • 状態が変わらないもの 157 値オブジェクト(もう少しつっこんで)
  159. 159 クレイグラーマン 実践UML

  160. 概念のカテゴリ 例 ビジネストランザクション ガイドライン:これらは重要(金銭を含むもの である)。これらを識別することから始めよう 販売、支払い、予約 トランザクション明細行 ガイドライン:トランザクションは通常、明細 行をともなう。従って次にこれらを検討する 販売明細

    トランザクションやトランザクション明細行に関与 する製品・商品・サービス ガイドライン:トランザクションは何か(製 品・商品・サービス)に関するものである。次 にこれを検討する 品物、飛行、座席、食事 トランザクションが記録される場所 ガイドライン:重要 記録簿、元帳、乗員乗客名簿 トランザクションに関係する人・組織が担う役割; ユースケースのアクター ガイドライン:トランザクションに関与する パーティ(人、組織を包含する概念)について 知る必要がある) レジ係、顧客、店舗、モノポリーのプレイヤー、乗 客、航空会社 160 クレイグ・ラーマン(実践UML)の概念カテゴリ
  161. 概念のカテゴリ 例 トランザクションやサービスが行われる場所 店舗、空港、飛行機、座席 注目すべきイベント。通常、時間や場所を覚えてい なければならない 販売、支払い、モノポリーゲーム、飛行 物理的対象 ガイドライン:組み込み系やシミュレーション ソフトを作るときには特に重要

    品物、レジスター、回路基盤、部品、金型、飛行機 物事の説明 製品仕様、フライト説明 カタログ ガイドライン:物事の説明はカタログに記載さ れていることが多い 製品カタログ、フライトカタログ 物や情報の入れ物 店、貯蔵箱、回路基板、飛行機、カート コラボレーティングシステム 認可システム、航空管制システム 財政、労働、契約、法的事項の記録 レシート、元帳、保守履歴 金融商品 現金、小切手、クレジットライン、手形 スケジュール、マニュアル、文書といった作業をす る上で参照されるもの 日次為替リスト、修理マニュアル 161 クレイグ・ラーマン(実践UML)の概念カテゴリ
  162. 162 責任関係型 責任関係型 責任関係 パーティ型 パーティ 期間 作業 0..* 0..*

    0..* 1 1..* 0..* 1..* 0..* 0..* 1 1 0..* 1 0..* 0..* 1 知識レベル 操作レベル
  163. 163 観測 人 観測 現象型 0..* 1 0..* 1 測定

    カテゴリ観測 量 1 0..* カテゴリ 1 0..*