Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

先日、某所でこれでしゃべってきました。内容的にはまだ書きかけのところがあるので、そこを仕上げたものを後日アップしようと考えています。

Hirohide Yazaki

February 06, 2020
Tweet

More Decks by Hirohide Yazaki

Other Decks in Programming

Transcript

  1. 所属 株式会社メソドロジック 取締役/CTO 専門 開発方法論、データモデリング、オブジェクトモデリングのコンサルティング 経歴 主に基幹システムの再構築プロジェクトにモデラーとして参画 某都道府県警の通信指令システム(いわゆる110番) テレビ局営報システム(番組編成・CM・放送 これDDDでやりました!)

    化学工業の生産管理 鉄鋼メーカー合併によるシステム統合 etc. 訳書 Writing Effective Use Cases(著者Alistair Cockburn)翻訳(2001年) Microservices IN ACTION(著者Morgan Bruce, Paulo A. Pereira )夏~秋出版予定 雑誌連載 JavaWorld ゼロから始めるオブジェクト指向(2001年~2002年11月) 日経オープンシステムズ UML/J2EEによるシステム構築の実際(2002年10月~2003年3月) 自己紹介 矢崎博英
  2. Unified Modeling Languageの略称 • 統一されたモデリング言語 • 国際的なオープンかつ非営利の技術標準化コンソーシ アムであるOMG(Object Management Group)が管理

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

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

    包)をなし、同一の本質をもつ一定範囲の事物(外延)に適用されることで一般性をもつ。例えば、 人という概念の内包は人の人としての本質的特徴(理性的動物あるいは社会的動物など)であり、外 延はその特徴をもつあらゆる人々である。・・・(略)・・・概念は言語に表現されて「名辞」と呼 ばれ、その意味内容として存在する。・・・(略)・・・ ②大まかで一般的な意味内容。 岩波書店 広辞苑 第七版 概念とは • 事物の本質的な特徴とそれらの連関が概念の内容(内包)なす • 同一の本質を持つ一定範囲の事物(外延)に適用される • 物理的に存在するものだけではなく、出来事やアイディア、観念上の存在物なども概念として 存在する
  7. 集合 集合とは、いくつかのものをひとまとめにして考えた’ものの集まり’ 数学的には“どんなものをとってきても、それがその集まりの中にあるか ないかがはっきりと定まっている“ようなものでなければならない 集合の記法(個々の集合を具体的に表す記法) • 外延的記法:集合の要素を列挙して集合を表す 例){1, 2, 3,

    4, 5, 6, 7, 8, 9} • 内包的記法:条件Pを示して集合を表す{x | P(x)} 例){x | 0 < x < 10, x ∈ ℤ} 集合の例 • 自然数全体の集合(ℕ)、整数全体の集合(ℤ)、有理数全体の集合 (ℚ)、実数全体の集合(ℝ)、複素数全体の集合(ℂ) • 当社社員全員からなる集合 11 集合
  8. 元(または要素) • 集合に含まれるものを元(または要素)という • 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} • 集合と元はベン図で表すことができる 12 集合 円は集合を表す 円の中にある点(や他の 図形は、この集合の元で ある(a ∈ A) a A ← 集合の名前 円の外にある点(や他の 図形)は、この集合の元 でない(b ∉ A) b 顧客 田原さん 近藤さん 松田さん 野村さん 中森工業 小泉百貨店 河合自動車 野口さん 山口さん パソコンX
  9. 13 概念モデルの第一歩→概念・集合をクラスで表す 顧客 田原さん 近藤さん 松田さん 野村さん 中森工業 小泉百貨店 河合自動車

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

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

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

    顧客 輸送車両 受注 商品 社員 物流拠点 自社 ドメインのスコープを表す枠 =全体集合 ドメインの中にはたくさんの 要素がある それらの要素を、概念が 適用される集合へと分類 する 集合・概念をクラスで表現する
  13. - お知らせメールを希望する : boolean = true - 顧客コード : 顧客コード

    - メールアドレス[1 .. 5] : メールアドレス - 生年月日 : 年月日 - 氏名 : 文字列 顧客 概念を説明するためのデータ項目を属性という 概念が適用される個体(要素)それぞれが自分自身の属性値を持つ (属性値がないという場合もある) UMLクラス図では属性区画に以下の形式で記述する 17 属性 属性名 属性の型 可視性 属性名:属性の型 [多重度] = 初期値 可視性 多重度 初期値 • 多重度は以下の形式で表す [多重度の最小値 .. 最大値] または、取りうる値の数列(カンマ 区切り) • 最大値が無い(いくらでもよい)場合はアスタリスク(*)で表す。 • 例) • [0..*] 0以上 • [1..*] 1以上 • [5..10] 5以上10以下 • [1, 3, 5] 1または3または5(0や2や4や6以上はだめ)
  14. 属性の詳細化を徐々に行っていく • 可視性は概念モデルでは基本的に不要 • 多重度はマルチバリューのときのみ • 初期値も必要なときのみで 18 属性 顧客

    お知らせメールを希望する メールアドレス[1 .. 5] 生年月日 氏名 顧客コード 顧客 お知らせメールを希望する : boolean メールアドレス[1 .. 5] : メールアドレス 生年月日 : 年月日 氏名 : 文字列 顧客コード : 顧客コード 顧客 お知らせメールを希望する : boolean = true 顧客コード : 顧客コード メールアドレス[1 .. 5] : メールアドレス 生年月日 : 年月日 氏名 : 文字列 顧客 概念を識別 属性を識別 属性の型を決める 初期値を決める 属性の初期値を決める
  15. 属性の型はプログラム言語の組み込みの型ではなく、値とし て取りうる範囲が示せる型を定める 例)属性「注文数」の型 × Integer(整数) 〇 自然数(または正の整数) これにより概念の性質がよりはっきりしてくる 以下を考えてみよう •

    数値や数字であれば、最小値、最大値が無いか • 文字列であれば桁数の最小値、最大値が無いか • 文字列であれば使用できる文字が限定されていないか • 値の刻みが無いか • なんらかの形式を持たないか(商品番号、メールアドレス・・・) 19 属性の型
  16. 識別子(IDやPK)で管理されないオブジェクト 例 • 住所(郵便番号×都道府県×市区町村×丁目番地×建物) • 量(数値×単位) 値オブジェクトの特徴 • そのドメイン内の何かの計測結果や説明のための値である •

    状態は不変。更新できない。何かの属性値を変えるときには、値オブ ジェクトを置き換える • 関連する属性を不可欠な単位として組み合わせることで、概念的な統 一体を形成する • 等しいかどうかは値の等しさでチェックする/できる IDDD本では値オブジェクトをできる限り使うことを推奨している 21 値オブジェクト
  17. 部署 - 単価 : 日本円 - 商品番号 : 商品番号 商品

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

    .. 最大値 ま たは、取りうる値の数列(カンマ区切り)で表し、 最大値が無い(いくらでもよい)場合はアスタリ スク(*)で表す。 • 0..* 0以上 • 1..* 1以上 • 5..1 5以上10以下 • 1, 3, 5 1または3または5 23 関連名・関連端名・多重度 - 単価 : 日本円 - 商品番号 : 商品番号 商品 - / 販売金額合計 : 10万未満の正整数 - 注文年月日 : 当社営業日 - 注文番号 : 注文番号 注文 - / 注文金額 : 10万未満の正整数 - 注文数 : 正整数 - 明細番号 : 正整数 注文明細 - 注文明細 1..* 1 - 注文品 0..* 1 - お知らせメールを希望する : boolean = true - メールアドレス[1 .. 5] : メールアドレス - 生年月日 : 年月日 - 氏名 : 文字列 - 顧客コード : 顧客コード 顧客 - 注文主 0..* 1 注文する - 子商品 - 親商品 0..* 0..1 {階層} 多重度 関連端 関連名
  19. 24 誘導可能性・メタ属性・再帰関連 誘導可能性 関連の一方からもう一方を参照できるかどうかを示す メタ属性 関連に制約や追加の意味を付与する。メタ属性を表す キーワードをブレイス({ })で括って表す 例){階層}, {ordered}

    再帰関連 同一概念の要素間に関連があることを示す 例) • セット商品はいくつかの単商品から構成される • グラフ理論: 頂点は辺でつながる 線の先が矢印 矢印の反対側から矢印側を参照できる 線の先が× ×の反対側から×側を参照できない 線の先が無印 誘導可能性は未定 - 単価 : 日本円 - 商品番号 : 商品番号 商品 - / 販売金額合計 : 10万未満の正整数 - 注文年月日 : 当社営業日 - 注文番号 : 注文番号 注文 - / 注文金額 : 10万未満の正整数 - 注文数 : 正整数 - 明細番号 : 正整数 注文明細 - 注文明細 1..* 1 - 注文品 0..* 1 - お知らせメールを希望する : boolean = true - メールアドレス[1 .. 5] : メールアドレス - 生年月日 : 年月日 - 氏名 : 文字列 - 顧客コード : 顧客コード 顧客 - 注文主 0..* 1 注文する - 子商品 - 親商品 0..* 0..1 {階層} 誘導可能性 メタ属性 再帰関連
  20. 集合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が成り立つ」というような言い方をする
  21. 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 = ∅ 27 演習:直積 答え
  22. 対応 • 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)
  23. 写像 • 対応の特別なケース。任意の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)
  24. 30 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のときは 写像
  25. f: A→Bを写像とする 32 写像の逆対応が写像になるとは限らない 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 写像の逆対応が写像になるケース 写像の逆対応が写像にならないケース
  26. Γ: A→Bを対応とする 33 写像でない対応の逆対応が写像になることもある A B Γ 1 2 a

    b c 3 d A B Γ-1 1 2 a b c 3 d 対応の逆対応が写像になるケース
  27. 大きくは次の4種類(0.. を加えるともっと多くの組合せ) • 1 対 1 • 1 対 多

    • 多 対 1 • 多 対 多 34 逆対応を逆の関連端の多重度で表す 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 多 対 多
  28. 36 回答案 - 場所 - 収容人数 - 会議室名 - 会議室ID

    会議室 - 備品ID 備品 - 予約取り消し区分 - 予約年月日 - 会議室予約番号 会議室予約 - 予約対象会議室 0..* 1 - 設置備品 - 設置先会議室 0..* 0..1 - 氏名 - 社員番号 社員 - 予約者 0..* 1 - 出席者 0..* 0..* - 名称 - 備品区分コード 備品区分 0..* 1 この多重度は ・予約者以外の出席者を示す関連だ とすれば最小値0(予約者が1人で 会議室を使う場合もある) ・そうでなくて予約者も含んだ出席 者を示すとすれば最小値は1 ・もっと言えば、予約者が出席する とは限らない(予約だけする人)の で、そう考えたら最小値は1にすべ き ・でも、ちょっと待てよ。先に会議 室だけとって、あとから参加者を決 める、というのもあるか。そういう 意味では参加者の設定はしてもしな くてもよい、とすべきか・・・
  29. 概念モデルでは属性と写像は実は同じものと考える 37 属性は写像でもある - 基本給 : 日本円 - Eメールアドレス :

    Eメールアドレス - 住所 : Address - 氏名 : String - 社員番号 : 社員番号 社員 社員 社員番号 - 社員番号 1 0..1 氏名 - 氏名 0..* 1 住所 - 住所 0..* 1 Eメールアドレス - Eメールアドレス 1 0..1 Money - 基本給 1 0..* 社員番号は共有されないの で多重度は高々1 同姓同名がいるかもしれか もしれないので多重度は 0以上 属性名は関連単名となる 属性型名はクラス名となる
  30. 写像を関数と呼び変えて、対応も写像(関数)とみなす ことで、概念間の関連は関数とみることができる 39 写像は関数 所属先部署 :: 社員 -> 部署 所属社員

    :: 部署 -> [社員] 社員番号 :: 社員 -> 社員番号 氏名 :: 社員 -> String 住所 :: 社員 -> Address Eメールアドレス :: 社員 -> Eメールアドレス 基本給 :: 社員 -> 日本円 部長 :: 部署 -> 社員 管理先部署 :: 社員 -> 部署 - 基本給 : 日本円 - Eメールアドレス : Eメールアドレス - 住所 : Address - 氏名 : String - 社員番号 : 社員番号 社員 - 部署名 : int 部署 - 所属先部署 - 所属社員 1 1..* - 部長 - 管理先部署 1 0..1 Haskell風に書いてみた 関連は、データベースのキーと外部キーの関係だけでなく、関数と してロジックでアウトプットされるものも含まれる 関数名 関数の始域: クラス名 関数の終域: クラス名 属性名や関連端名が 関数名になる []はリストを 表す
  31. 対応のグラフ、写像のグラフΓ 対応 Γ :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)} 40 対応/写像のグラフ 40 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
  32. 社員 プロジェクト - プロジェクトメンバー - 参画プロジェクト 0..* 0..* - 参画期間

    : 期間 プロジェクト参画 ロール - プロジェクトでの役割 1..* 0..* 関連クラスはいつ必要か 対応/写像のグラフが属性/関連を持つとき • プロジェクト参画は参画期間という属性を持つ • プロジェクト参画はロールと関連を持つ i.e. 対応、写像のグラフが、対応/写像の始域となるとき プロジェクトでの役割: プロジェクト参画 → ロール 参画期間 : プロジェクト参画 → 期間 41 対応/写像のグラフは関連クラスで表す 関連クラス 関連線に点線で つながる
  33. {階層}は、組織の上位・下位の関係がツリー構造になっ ていることを表す 43 関連の代表的なメタ属性1 階層 組織 {階層} - 下位組織 -

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

    組織 係1aあ : 組織 係1aい : 組織 係1aう : 組織 係1bえ : 組織 係1bお : 組織 部2 : 組織 課2a : 組織 課2b : 組織 係2aあ : 組織 係2aい : 組織 係2bう : 組織 係2bえ : 組織 課2c : 組織 このリンクは許されない ツリー構造ではない 下位組織 上位組織
  35. {階層}は ツリー構造であることを 指定しているだけ 左記のような構造も許さ れる これを許さないためには 別の方法が必要 45 階層:これは許される 部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 : 組織 部の下に課をはさまずに係 た直接ついている 係の下に課がつく
  36. リストは自然数から対象への写像(部分関数)であ る 路線のリスト : ℕ → 停留所 0→渋谷駅, 1→ 道玄坂上,

    2→大阪上 リストのことを点列ともいう(対称が数値なら数列) 47 リストの数学表現
  37. 集合Aの任意の元が集合Bの元であるとき、AはBの部分 集合であるといい A ⊂ B と書く • AはAの部分集合である • ∅は任意の集合の部分集合である

    • A ⊂ B かつ B ⊂ A ならば A = B • A ⊂ B かつ A ≠ B ならば AはBの真部分集合とい う 部分集合 A a b c
  38. 59 対応の制限 Γ|有料会員 ▶ プロジェクト ロール * 1 プロジェクトリーダ エンジニア

    * Γ = アサイン 1 対応先も部分集合になることを明示する 多重度が変わる(対応から写像に変わる) Γ|プロジェクトリーダ ▶ 会員 有料会員 購入 有料会員購入 会員 有料会員 購入 - 購入 - 会員 0..* 1 Γ = 購入 - 獲得ポイント数 有料会員購入 0..* 1 プロジェクト ロール インスタンス PG SE PL PL PG SE
  39. • 経営資源を表す概念 • 社内組織(事業部、部、課、社員、協力会社、その分類の性別、資格など) • 社外組織(顧客、卸、銀行、その分類の業種、地域など) • 設備(工場、建機、金型、事務所など) • 品役(商品、資材、サービス、その分類など)

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

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

    • リソースや在庫のある時点(年末、4半期末、月末、週末、日末など)の状態 の記録を概念として把握したもの • 月末商品在庫、商品履歴、貸借対照表 • 要約 • 通常イベント、定時イベントの主に数値属性のある期間の要約の記録を概念と して把握したもの • 四半期別商品別売上実績、月次社員別稼働実績、損益計算書 • 要約のキーは期間に加えて、他のオカレンスリソース(部署、社員、顧客な ど)が用いられる場合がある • 要約されるデータは合計、平均、最大、最小、中央値、最頻値、最近値など 66 THモデル:在庫、断面、サマリー
  42. 概念のカテゴリ 例 ビジネストランザクション ガイドライン:これらは重要(金銭を含むもの である)。これらを識別することから始めよう 販売、支払い、予約 トランザクション明細行 ガイドライン:トランザクションは通常、明細 行をともなう。従って次にこれらを検討する 販売明細

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

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