オブジェクト指向モデリング技術の現在と未来9 hanyuda eiiti，mamezou 2010.11.2...

2010.11.2 Hanyuda Eiiti，Mamezou 1

株式会社豆蔵取締役CTO/フェロー

技術士（情報工学）羽生田栄一

2010年11月2日

JavaFesta2010 in 札幌

【B-1】オブジェクト指向モデリング

技術の現在と未来

2

これは何でしょう？

2010.11.2Hanyuda Eiiti，Mamezou

人はなぜモデルを見ると喜ぶのか?

認識過程の逆転が快感になる（レヴィ・ストロース『野生の思考』）

実物大の対象を前した場合、部分の認識から始めて、それらを総合することで全体の認識へ達する。

モデル(模型)の場合、全体の認識が真っ先に到来し、次に部分の認識が来る。その認識の逆転をもたらすのは、さまざまな要素の縮減そして削除である（抽象化）ミニチュアではサイズが、絵画では体積が、彫刻では色・匂い・触感が、

ほとんどの場合、時間の次元が切り落とされる（動的ダイナミクス）

それにより、実物のもつ抵抗が克服され（記述）

自分の主体性の確立が感覚されるからである（操作可能性）

2010.11.2Hanyuda Eiiti，Mamezou3

4

モデルとは何かモデルとは関心のある対象世界を、目的に適した視点で捉えて

抽象化・形式化し、理解・操作しやすく記述したもの例）車とプラモデルの車（田宮模型：ポルシェカレラGT）

現実の車の目的は「人を乗せて走ること」であり、プラモデルの車の目的は「見た目や組み立て過程を楽しむこと」

「外観」や「作成過程」という側面を重視し、それ以外の現実の車の機能は省き、単純化している

モデリングとは対象世界を分析し対応するモデルを作成する過程

モデルベース開発とは開発対象に関係するモデルを中心にすべての開発

プロセスを進めていくこと2010.11.2Hanyuda Eiiti，Mamezou

システム開発とモデル

システム化対象の本質（概念構造概念構造）を抜き出し、S/Wの世界で実現する

システム化対象S/Wシステム（実装結果）

抽象的問題領域（分析結果）

抽象的解決領域（設計結果）

現実世界仮想世界

難解で複雑

抽象化具象化施設一覧の取得施設一覧の取得

施設名の取得

施設名の取得

施設名の取得施設の予約空き施設の取得

モデルモデル

業務・課題情報システム 52010.11.2Hanyuda Eiiti，Mamezou


モデリン

グ技術

UMLの使い方事例


8

UMLダイアグラムと開発の関係開発工程要求分析分析設計実装テスト

モデル名要求モデル分析モデル設計モデル実装モデルテストモデル

UMLダイアグラム

その他の

成果物

アクティビティ図

コンポーネント図

相互作用図（主にシーケンス図）

クラス図

コンポジット構造図

オブジェクト図パッケージ図配置図

ステートマシン図

ユースケース図

テストケースソースコードユースケース記述

シナリオ

特に重要なダイアグラム

補助的なダイアグラム



開発におけるモデルの２つの効用モデルの効用は

コミュニケーションを媒介すること：

（1）対象業務の関係者と開発者

（2）開発者どうし

予約係空き部屋台帳

ホテル

モデルモデル利用者

業務・要求業務・要求

モデル化

クライアント

データベース

サーバ

システムシステム

実現

(1)業務世界と開発者

(2) 開発者どうし

ステークホルダ間の調整

適切なアーキテクチャの設計・実装

2010.11.210

ユースケースからオブジェクトへ（Jacobson ロバストネス分析）

ユースケースUi

Model

ControlView

Actor

System

コラボレーションCi

ユースケースの機能をオブジェクト達の協調（コラボレーション）として実現する

Hanyuda Eiiti，Mamezou

11

ユースケースモデル

配置図

パッケージ図

設計モデル

分析モデル

クラス図


シーケンス（相互作用）図

UMLによるモデリングの繰り返し


12

ソフトウェアパターンの基本構成項目説明内容

名前キャッチコピーそのパターンを的確に想起させる語彙＝キーワード

状況 When（こんなとき）ある機能をもつソフトウェア（部分）の開発＝設定

問題 What（こうしたい）ある（非機能）要求を満たしたいという課題＝目的

解決 How（こうせよ）ソフトウェア設計の方針と具体的解決策＝解法

結果 What（こうなる）得られたたソフトウェアにおいて機能／非機能要求が満たされた状況と注意点＝効果・副作用

理由 Why（なぜなら）問題と方針・解決策の対応関係、機能／非機能要求の満足に有効であった理由＝フォース


13

デザインパターン・マップ

Builder Memento

Decolator

Strategy

Iteretor

Flyweight

Composite

Visitor

Interpreter

TemplateMethod

AbstractFactory

Singleton

Prototype

Facade

FactoryMethod

Observer

MediatorState

Command

Adapter

Bridge

Proxy

Chain Of Responsibility

インスタンスを１つだけ生成する

インスタンスを１つだけ生成する

～を使って生成する

しばしば使用する

State(状態)を共有する

アルゴリズムのステップを定義する

殻(外見)の変更対

中身の変更

オブジェクトに責任を追加する

Strategy(戦略)を共有する

オブジェクトの巡回手順を定義する

複合オブジェクトを生成する

責務の連鎖を定義する

Iterationの状態を保存する

要素に対する操作を追加する

要素に対する操作を柔軟に追加する

デリミタを共有する

末端の要素を共有する

～を使って組み立てる

文法を定義する構文を分解する

複雑な依存関係を管理する

子オブジェクトを数える

過去の操作を記録する

Factoryを動的に構成する

生成パターン

構造パターン

振る舞いパターン



モデリン

グ技術

15

SysMLとは何かOMG 2007年09月Version 1.0 正式版公開

2008年11月Version 1.1 正式版公開

システムエンジニアリング向けの汎用モデリング言語ソフトウェア、ハードウェアを含む「システム」全体をモデリング対象とする

「ソフトウェア・システム」よりも対象範囲が広い

システムの要件定義、分析、設計、検証、妥当性確認要件定義、分析、設計、検証、妥当性確認の記述を支援するためのダイアグラムを提供 UML2の拡張プロファイルとして定義されている

UML2にいくつかの図を追加、UML2のいくつかの図を除く

記述可能な対象：

システムシステムとそこに含まれる、ハードウエア、ソフトウエア、データ、要員、機能、設備、など

SysMLで定義していないもの：方法論、ツール (←UMLと同様に表記法のみを定義)


16

SysMLのダイアグラム：UMLの拡張SysMLはできるだけUMLを流用するというコンセプトで定義

UMLで足りないセマンティクスと表記法を新たに定義

SysMLUML2

UMLを利用している部分

UMLを拡張している部分SysMLに含まれない部分

ステートマシン図シーケンス図ユースケース図パッケージ図

要求図パラメトリック図

アクティビティ図ブロック定義図(UMLのクラス図相当)内部ブロック図(UMLのコンポジット構造図相当)

SysML固有の拡張/制限を追加

SysML特有の図を追加

UMLの図をそのまま流用

オブジェクト図コンポーネント図配置図コミュニケーション図相互作用概要図タイミング図

SysMLでは使われない図


17

SyｓMLダイアグラム例：要求図要求とテスト・ケース、それらの間の確認関係<<verify>> ある要求が満たされているか否かを検証・検査するための方法を表わす

《testCase》JISB8346騒音レベル

JIS B 8346 「送風機及び圧縮機－騒音レベル測定方法」に準拠。

《testCase》JISC9601風速

《testCase》JISC9601風量

JIS C 9601 「扇風機」に規定された測定方法に準拠。

Text = "連続運転時の騒音レベルは45dB未満であること。"ID = "REQ123"

《requirement》静粛性

《verify》テスト・ケース・アイコンテスト・ケース名

確認関係このテスト・ケースによって表現されている方法によって確認される要求を示す。


18

SyｓMLダイアグラム例：パラメトリック図 {他のブロックの|複数のブロックに跨る}プロパティを制約するための制約ブロックの使われ方を表現するための図

par 電動機 [電動機の力学制約]

すべり : すべり公式S:

Ns:

N:

回転速度 : 同期回転速度公式

Ns:

f:

p:

出力 : 出力公式

N:

効率 : 効率公式

P:

力率 : 力率公式

η:

P:

W:

Pf:

W:

E:

I:

すべり:Real

電源周波数:Hz

極数:Integer

T:トルク:NewtonMeter

出力:Watt

効率:Real

力率:Real定格電圧:Volt

実回転数:RevolutionsPerMinute

全負荷電流:Ampere

制約プロパティ値プロパティパラメータ

コネクタ正確には『Binding Connector』という等値になる要素同士をむすぶコネクタ。

パラメータ名ここでは型は省略されている。


19

SysMLダイアグラム間の関係

d1:Traction Detector

m1: Brake Modulator

c1:modulatorinterface

ibd [block] Anti-LockController[internal Block Diagram]

Vehicle SystemSpecification

req [package] VehicleSpecifications[Requirements Diagram – Braking Requirements]

Braking SubsystemSpecification

《deriveReq》

Detect Loss OfTraction

ModulateBraking Force

act PreventLockup [Activity Diagram]

tf: tl: bf: cpar [constraintBlock] Straight Line Vehicle Dynamics [Parametric Diagram]

:Braking ForceEquation[f = (tr*bf)*(1tl)]

:AccellerationEquation[F = ma]

: Distance Equation[v = dx/dt]

:Velocity Equation[a = dv/dt]

f:

F:

a:a:

v:

v:

x:

1. 構造

3. 要求 4. パラメトリック

2. 振舞い

Satisfies《requirement》Anti-LockPerformance

allocated Form《Object Node》Traction Loss:

allocated Form《activity》 Detect LosOf Traction

allocated Form《activity》 ModulateBraking Force

ValuesDuty Cycle: Percentage

id=“102”text=“The vehicle shall stopfrom 60 mph within 150 fton a clean dry surface.”

《requirement》StoppingDistance

Verified By《interaction》 MinimumStopping Distance

id=“337”text=“Braking subsystem shallprevent wheel lockup under allbraking conditions.

《requirement》Anti-LockPerformance

Satisfied By《block》 Anti-Lock Controller

《allocate》Traction Detector

《allocate》Brake Modulator

allocated To《connector》 c1: modulator Interface

Traction Loss

tf: tl: bf:

v.chassis.tire.Friction:

v.brake.abs.m1Duty Cycle:

v.brake.rotor.Breaking Force:

v.Weight:

v.Position:

m:

割り当て

値への制約

Verify

実現

4本柱の間には対応関係が存在


20

MDD（モデル駆動開発）に向けて: UML/SysMLによるモデリングの意味矛盾のないモデル

対応関係対応関係

対応関係

対応関係静的構造

動的構造機能構造

トレース

対象

モデル化

モデル化モデル化

対応関係

対応関係

モデルに矛盾や過不足が

ないかを検証検証

クラス図


シーケンス図

アクティビティ図や数式

理解理解モデル検証検証



モデルは有機的に連携しているモデルに対応したプロセス例（一部）

要望要求リスト

機能要求

非機能要求ユースケース図リストアップ

モデル化

ユースケース記述

詳細化イベントフローを

モデル化

文章化

アクティビティ図

クラス図ステートマシン図

a:A b:B c:C

2:xxxx1:xxxx

シーケンス図アクティビティ図

モデルの検証

フィードバック

クラス図ステートマシン図

a:A b:B c:C

2:xxxx1:xxxx

シーケンス図アクティビティ図

モデルの検証

フィードバックパッケージ図

配置図アーキテクチャ検討

コンポーネント設計

要求定義

要求分析

設計


システム開発地図（豆蔵）

地図で成果物のトレーサビリティ

作業工程

作業の成果物output

成果物同士の関連と作成する順番

要素同士の関連と矢印の方向は、変換方向


詳細は、豆蔵ソフト工学ラボ：『システム開発地図第1回：エコな開発を』http://labo.mamezou.com/special/sp_015/sp_015_001.html

システム開発地図の効果属人性の排除成果物をどの程度の完成度(後続作業が開始できる程度)にすればよい

か、どのような入力を求めればよいかがわかる

経験の有無によらず成果物の粒度をそろえることができる

直前・直後の作業と成果物の関連を理解できる

課題がどの設計・要求に影響するのか追跡しやすい

品質の担保

重複・漏れを防ぐことができる

分析・設計・実装の一貫性を保つことができる

成果物間の整合性を保つことができる

わかりやすさ

作業と成果物の位置づけを容易に把握できる

作業の詳細を学ぶ前に、作業の全体の中での位置づけ・意義がわかる

組織に合わせたカスタマイズが容易となる


ソフトウェアパターンの適用のしくみ

前提(コンテキスト)

パターンユーザ

問題

フォース(力)

解決の仕組み(構造)

状況にいる

▼ を抱えている

に優先順位を付ける ▼

を満足する（Resolves） ▲

を解決する（Solves）

問題解決の考慮点（Concerns）、あるいは解

が持つべき特性（Aspects）

の記述

中心となる問題を記述する

*

*

2010.11.225 Hanyuda Eiiti，Mamezou

26

アナリシスパターンアナリシスパターン

デザインパターンデザインパターン

アーキテクチャパターンアーキテクチャパターン

データモデルパターンデータモデルパターン

プロセス／組織パターンプロセス／組織パターン

アンチパターンアンチパターン

テストパターンテストパターン

ドメイン指向デザインパターンドメイン指向デザインパターン

さまざまなパターンとユーザ

要求分析担当者要求分析担当者

SEPGSEPG

アーキテクトアーキテクト

実装担当者実装担当者テスト担当者テスト担当者

データベース設計者データベース設計者

SQASQA

UIデザイナーUIデザイナー

教育担当者教育担当者

UIデザインパターンUIデザインパターン

プロジェクトマネージャプロジェクトマネージャ

実装パターン/イディオム実装パターン/イディオム

コンテキスト、立場によってパターンを使い分ける

アジャイル開発者


パターンのカテゴリ分類

有機的体系体系

汎用性知恵・方針知恵・方針

目的性知識・手段知識・手段

学習パタンランゲージ

eビジネスパターン（IBM）

個別的カタログカタログ

デザインパターン

アーキテクチャパターン

アナリシスパターン

アンチパターンオブジェ

クト指向設計原則

プロセス組織パターン

フレームワーク A Pattern Language

(Alexander)

Nature of Order

(Alexander)

パタンランゲージ

ソフトウェアパターン

原理原則

ストリームラインモデリング

REAビジネスパターン XP

(Kent Beck)


POSAにおけるパターンの分類アーキテクチャパターンデザインパターンイディオム

システムの構造化レイヤー化、パイプ＆フィルターブラックボード

Interpreter

分散システムブローカー

対話型システム MVC（model-view-control）

PAC (presen-abstraction-control)

適応型システムマイクロカーネル、リフレクション

作業の組織化 Master-Slave

Chain of Responsibility

Command, Mediator

サービスの多種化 Bridge, Strategy, State TemplateMethod

サービスの拡張 Decorator, Visitor

管理 Command Processor

View Handler, Memento

アダプテーション Adapter

コミュニケーション Publisher-Subscriber

Forwarder-Receiver

Client-Dispatcher-Server

リソースハンドリング Flyweight CountedPointer

生成 Abstract Factory, Prototype, Builder

構造分割 Whole-Part, Composite

アクセス制御 Proxy, Façade, Iterator


ファウラーのPoEAAのレイヤー構成

レイヤー目的関連するPoEAAパターンの例

プレゼンテーションレイヤー

サービスの提供や情報の表示（GUI・HTTPリクエスト・コマンドライン・バッチAPI等の処理）

MVCApplicationController

ドメインレイヤーシステムの本来のロジックの実行

Transaction ScriptDomain ModelTable Module

データソースレイヤー

データベース・メッセージングシステム・トランザクションモニター等のミドルウェアパッケージとの通信

GatewayActive RecordData Mapper


システム開発のパターンランゲージ化IBM Patterns for e-business


セルフサービス・ビジネスパターンを実現するアプリアプリケーションパターンケーションパターン候補とビジネス要件/IT要件

アプリケーションパターン種別

ビジネス要件

スタンドアローン

シングルチャネル

直接統合


現状維持ホスト

ホストへのカスタマイズ・

プレゼンテーション

ルーター

デコンポジション

エージェント

迅速なビジネス開始 ○ ○ ○

組織の効率の改善 ○ ○ ○ ○ ○

ビジネスプロセスの迅速化

○ ○ ○ ○

M&Aへの柔軟な適応 ○ ○ ○

複数のデリバリ・チャンネルの統合

○ ○ ○

業務種別を通して顧客からみたビューの統一

○ ○

関連する商品サービスの効果的な販売連携の支援

○

一括カスタマイズ ○

アプリケーションパターン種別

IT要件

スタンドアローン


直接統合


現状維持ホスト

ホストへのカスタマイズ・

プレゼンテーション

ルーター

デコンポジション

エージェント

アプリケーションの複雑さの最小化

○ ○

TCO（Total Cost of Ownership）の最小化

○ ○ ○ ○ ○

既存の組織・人材スキルの有効活用

○ ○ ○ ○ ○ ○

既存システムの有効活用 ○ ○ ○ ○ ○ ○

バックエンドアプリケーションの統合

○ ○ ○ ○ ○ ○

企業全体の複雑さの最小化

○ ○ ○

保守容易性 ○ ○ ○

拡張容易性（スケーラビリティ）

○ ○ ○


アプリケーションパターンおよび対応するランタイムパターンの例

(2) 「直接統合・シングルチャネル」アプリケーションパターン

(1)「スタンドアロン・シングルチャネル」アプリケーションパターン


(3) 「スタンドアロン・シングルチャネル」の基本ランタイムパターン(4) 「スタンドアロン・シングルチャネル」の派生ランタイムパターン

注）いずれも参考文献：IBM Patterns for e-businessより引用



モデリン

グ技術

ソフトウェア工学のテーマ交代プロダクトプロダクトとプロセスプロセスへの興味が交代

21世紀2000年代以降の特徴

プロダクトラインプロダクトラインはプロダクトとプロセスの両方を融合

アジャイルアジャイルと形式手法形式手法の両方が注目される


オブジェクト指向オブジェクト指向構造化構造化

玉井哲雄「ソフトウェア工学の40年」より改変

管理技法管理技法プロダクトラインプロダクトライン

アジャイルアジャイル

形式手法形式手法

CASECASE

1970年代 1980年代 1990年代 2000年代

Hanyuda Eiiti，Mamezou36

プロダクトラインエンジニアリングへ

基本プロセスｘアーキテクチャ統合統合

再利用ソフトウェア資産による高品質・俊敏開発再利用ソフトウェア資産による高品質・俊敏開発

プロセス改善プロセスプロセス改善開発技術革新開発技術開発技術革新

開発組織の在り方開発組織の在り方：プロセスプロセスとアーキテクチャアーキテクチャの有機的な活用

高品質な再利用可能なソフトウェア資産（フレームワーク、コンポーネント）を用いて開発プロセスを実行し、生産性の向上・品質の向上・短期開発を実現

これはソフトウェアプロダクトラインソフトウェアプロダクトラインの考え方：

特定の市場分野あるいは課題（ミッション）に特有のニーズを満たし、

事前に記述された方法を用いて、共通のコア資産をもとに共通のコア資産をもとに作られる

共通の管理された特性を共有するソフトウェア集約型システムの集合

2010.11.2

未来のモデリングの条件

アジャイルなプロセスと形式手法の融合

業務やサービスの環境のオントロジー駆動

プロダクトライン・エンジニアリングの実用化

DDD（ドメイン駆動開発）の進化形進化形



形式手法（Formal Method）とは論理学や数学にもとづいて、厳密な仕様厳密な仕様（形式仕様：Formal Specification）を作り、それを基に正しく開を基に正しく開

発発を行う手法-- クライアントがEventの発生をポーリングするためのインターフェイス-- クライアントが所持しているEventに対して、新しいEventが発生しているか判断し、そうであるならば新しいEventを返す。そうでない場合はnilを返

す。Get_New_Event(prev_e: [Event]) new_e: [Event]ext rd event_occured: [Event]pre truepost(event_occured = nil and new_e = nil) or(event_occured <> nil and ((event_occured = prev_e and new_e = nil) or(event_occured <> prev_e and new_e =

event_occured)));

QUEUE = P<>P<> = enQueue?x → P<x>Ps Ù<x> = ( enQueue?y → P<y>Ùs Ù<x> |

deQueue → Ps |front!x → Ps Ù<x>)

/* 車は同時には2つ以上の料金所にアプローチする/いることができないという制約。*/fact car_at_most_one_tollgate {all c: Car, t: Date |no disj s, s': ETC_Tollgate | some s.car && some s'.car && s.car = s'.car &&s.id != s'.id && // overlapDO/gte[s.pass.from, s'.pass.from] &&

DO/lte[s.pass.from, s'.pass.to]}

2010.11.2

形式手法におけるモデルの役割

モデル

ダイアグラム1 ダイアグラム2 ダイアグラムN

実行エンジン

役割1.ダイアグラムやモデル要素間の制約の正確な表現

役割2. モデル実行による制約の検証・要求シミュレーション


40

LFM（Lightweight Formal Methods）

形式手法の自動検証ツールを前提ツールを前提とした手法 1990年代半ばにモデル検査の中から提唱される代表的な言語/手法

モデル検査法モデル検査法： SPINSPIN（言語： Promela）、SMV 拡張静的チェッカー拡張静的チェッカー： ESC/Java2 構造モデル制約記述解析ツール： Alloy、UML/OCL

従来の形式手法とは考えが異なる

従来の形式手法仕様に欠陥がないことを証明証明する（証明）

”正しい”仕様から”正しく”導出導出//構成構成する（段階的詳細化）

LFMの場合

シミュレーションシミュレーションややプロトタイピングプロトタイピング環境を提供環境を提供 Agile ModelingAgile Modeling 欠陥の早期除去の道具欠陥の早期除去の道具として割り切りツールツール重視重視


AlloyおよびAlloyAnalyzerby D. Jackson MIT

1階述語論理（1階関係論理）とオブジェクト解釈

SATソルバーによる制約充足問題解決へ

Z記法の自動解析可能なサブセットの位置づけ

検証verificationより不具合発見falsificationのツールとしての有用性

有限スコープ仮説：初期状態からの探索の深さを制限しその範囲を網羅的に調べることで不具合は発見できる

仕様（クラス定義）を与えインスタンス例を生成インスタンス例を生成

Agile Modeling環境（クラス図の妥当性確認クラス図の妥当性確認）＊豆蔵：小林が日本語使えるようにAlloyAnalyzer改変


ポストJava言語の条件？形式手法・実行可能仕様との親和性

1. C/C++/Javaの言語の伝統を踏まえていること JVMを使うだけでなく、強い静的型付けまで入れるか？Yes！

2. 柔軟で簡潔な記述ができる言語文法であることある種の動的性が必要！動的言語だけを意味しない！＋パタンマッチング

3. スケーラビリティや並列性に対する工夫が見られることクラスの継承＋Mixin＋関数＋安全でスケーラブルな並列性

4. 実用的なフレームワークやライブラリ、ツールが備わっていること5. DSL（ドメイン記述言語）として拡張できること

言語の柔軟な拡張性（ライブラリの追加が言語の拡張と見做せる）

6. 既存のソフトウェア資産との相互運用性があること既存のコードの柔軟な再利用、拡張による新規コードの記述

7. コンピュータサイエンスや言語処理系の理論的成果をうまく取り入れていること

型理論、アクター等並列モデル、継続、アスペクト、Mix-in、言語理論

8. 既存のJavaプログラマの支持を受け十分な開発者が確保できること

関数型オブジェクト指向言語関数型オブジェクト指向言語ScalaScalaのモデリング言語モデリング言語としての可能性 2010.11.242 Hanyuda Eiiti，Mamezou

DSLとしてのScalaの可能性：ケースクラス日本語で語彙（型・関数・変数）自由に表現！

1. case class `住所`(adr: (Int, String, String, String))2. case class `利用者`(`登録id`:BigInt, `氏名`:String, `連絡先`:`住所`)3. case class `図書`(`書名`:String, `図書id`:BigInt){4. def `を貸し出す=>`(`借り手`:`利用者`) }5. val `段田塊太` = `利用者`(9200800345, “段田塊太”, `住所`(101630434,

“新宿”, “2-1-1”, “スカラ座ビル”))6. val `本1`=`図書` (“はじめてのスカラ”, 1200700077)7. `本1` `を貸し出す=>` `段田塊太` <= `本1`.`貸し出し`(`段田塊太`)

要求コードのトレーサビリティの確立日本語で書いた要求を日本語のクラスとメソッドで仕様化し、

日本語の変数や文字列でプログラミングできる！

関数が第1級言語要素でありかつオブジェクトである OO言語ドメインオブジェクトの記述関数型制約やビジネスルールの記述

エリクソン/ペンカービジネスモデルのオントロジー（メタモデル）

抽象存在

制約導出存在情報

ヒト

物理存在

モノ

{incomplete}

インターフェイス

イベント状態変化

リソース*

*

*

*

refers to

**

affects

ルール*

*

*

*

refers to*

**

*applies to

プロセス

**

**

generates

**

**

affects

**

causes

1..*

*

1..*

* *

*

*

*

governs/controls

**

part of

* *

ゴール**

can be expressed as

*

*

*

*expresses desired states of

**

achieved by

*

*

*

*

part of

問題

1..*

*

1..*

*

hinders the achievement of

**

**

part of


エリクソン/ペンカーのビジネスモデリングパターン：４つのビジネスビューとダイアグラムビジネスビュー

モデリング対象ダイアグラム主要な関係者

ビジョンビジョン戦略定義 SWOT分析マトリクス経営者

概念構造概念クラス図上級マネージャBizアーキテクトゴール問題ゴール問題ツリー図

プロセスプロセスプロセスと入出力プロセス図、アセンブリライン図 Bizアーキテクトマネージャ

構造構造リソースリソースクラス図

Bizアーキテクトマネージャ

情報情報図

組織クラス図、オブジェクト図

振る舞い振る舞い状態ステートマシン図プロセス定義者

相互作用シーケンス図、アセンブリライン図


リソースとルール・パターンの１つ「雇用(Employment)」パターン

ポジションアサイン

雇用

1..*

1..*

1..*

1..*

of (in)

based on

ポジション

the source of (with)

パーティ

ヒト組織

filled by (to)

responsible for (defined by)

Birthdate

Name Address

Purpose


プロセスモデリングパターンの１つ「基本プロセス構造」パターン

<<process>>:P1

<<goal>>g1:ゴール

入力オブジェクト：aClass

出力オブジェクト：ｂClass

<<resource>>資源A

<<resource>>資源B

<<achieve>>

<<supply>><<supply>>


2010.11.248

<<assembly line>>在庫システム

<<assembly line>>販売システム

<<assembly line>>会計システム

<<process>>販売の確認

<<process>>Transactionの登録

<<process>>Orderの配達

use case S1 uc S2 uc S1 uc A1 uc I1 uc S3

ビジネスプロセスとユースケース

Order

情報の獲

得販売員の識別

売上の記録

Order

情報の獲

得

new Transaction

の生成

受取可能Account

の登録

Order

の識別

積荷リストの獲得

在庫

の更新

配達済みの記録

Hanyuda Eiiti，Mamezou


最近登場:斬新なビジネスモデリング方法

UMLを使用、単なるモデリングノウハウではない

経済行為というものの意味（オントロジー）

モノ・コト・ヒトの３大基本要素 R（Resource, 資源）、E（Event, イベント）、A（Agent,主体）

常に満たすべき制約条件とそれらの間に成立する相互作用をスケルトンとして実際のビジネスをモデル化

ビジネストランザクションとは、経済リソースの交換

「ある経済リソースの価値を増やすために、通常はいくつかの経済リソースの価値を下げる」というプロセス

必ず価値の「交換の双対性交換の双対性（そうついせい、duality）」が成立

REAビジネスパターン

REAの基本概念モデルとREA交換プロセスの双対性


REAの双対性にもとづく販売プロセスのモデル化


REAの構造（３レイヤーで構成）

(1)業務レベル業務レベルの構造パターン[REAREA基本原理基本原理：実際のビジネストランザクションを表現] REA交換プロセス、REA変換プロセス、REAバリューチェーン

(2)方針レベル方針レベルの構造パターン[どのビジネストランザクションが起きるべきかを表現] タイプ、グループ、コミットメント、契約、スケジュール、方針、連

結、責任、監督

(3)振る舞い振る舞いパターン[特定のビジネスニーズに応じてREAをアスペクト指向で拡張] 基本：識別、期日、説明、注釈、ロケーション、分類、通知、価値

財務：転記、勘定、照合、実体化した請求権

新規：考案者のパラドックス



モデリン

グ技術


21世紀の長期展望：

知的世界観の大転換１９世紀から２０世紀へ構造主義革命，言語論的転回

世界は『言語』で構造化されている

コンピュータコンピュータはその価値観の申し子形式、機能、ルール、仕様定義、工学、分業、経済効率原則

“コミュニケーションコミュニケーション”の２１世紀バージョン

• ２０世紀から２１世紀へ– 認知意味論・認知身体論・メディア論的転回

–– ココロココロは環境環境世界とカラダカラダを媒介するメディア（身体性）媒介するメディア（身体性）

– 対象領域に対しカラダの構えとして意味をモデル化

–– ?????? （モデリング・パタン・アジャイル）（モデリング・パタン・アジャイル）はその価値観の申し子– 環境世界にカラダで反応するココロの活動内容、環境のオントロジー

– 意味、価値、サービス、プロセス、アート、協働、環境生態原則

シンタックスの時代シンタックスの時代

セマンティクスの時代セマンティクスの時代

過去

現在

未来

2010.11.2

55

オブジェクト指向の基本１

クラスとインスタンス

カプセル化

継承（inheritance）と委譲（delegation）

UMLモデルの汎化関係は，継承か委譲で実装

委譲＝デリゲーションをデザインパタン本ではコンポジションという

関連や集約で保持した部分オブジェクトにメッセージを転送し代理実行を依頼する

ポリモルフィズム

インターフェースと実装クラス

設計ビュー


56

オブジェクト指向の基本２：OCP

｛abstract｝AbstractServerClient

ServerClientA

Server’ClientB機能拡張Copy&Edit

Server Server’

派生クラスの追加

①変更の可能性があるところ(HotSpot)を見つける②その部分を抽象化してスーパークラスにする③スーパークラスのサブクラスで変化に対応する※ClientA,Bは、Server/Server’をAbstractServerとして利用する

Open Closed Principle（開閉原則）

拡張には拡張にはOpen,Open, 修正には修正にはClosedClosed 既存のクラスを修正せずに機能を拡張できるようにすること

従来

オブジェクト指向

設計ビュー


57

オブジェクト指向の見直し世界を分節化して意味を取りだす単位＝概念

環境世界のOntology

概念ビュー

詳しくは、まつもと他『ソフトウェアの匠』（日経BP社2004）の羽生田「オブジェクト論」http://www.amazon.co.jp/dp/4822206653/

「イヌ」としてのポチ！認識＝判断認識＝判断

ポチはイヌのインスタンスである！

概念分類構造概念分類構造

哺乳動物

イヌネコ

問題状況の中での対象＝個体の識別対象＝個体の識別

ある目的を持ったコミュニティの中で区別する（管理する）ことに価値のある概念区別する（管理する）ことに価値のある概念が

環境の中から浮かび上がってくる！

DDDDDDが目指すのも

この意味での概念＝ドメインオブジェクトドメインオブジェクト


意味の3角形:比喩の3形態とオブジェクト指向

類似性類似性

隣接性隣接性汎化関係汎化関係

オブジェクトの関連・集約[オブジェクトの接続構造]

クラスの汎化・継承[オブジェクトの概念分類]

メッセージによるポリモルフィズム[オブジェクトの振る舞いの類似性]

類推する力類推する力

認知言語能力認知言語能力

隠喩隠喩（メタファー）

（シネクドキー）

提喩提喩

参照する力参照する力分類する力分類する力

（メトニミー）

換喩換喩

概念ビュー

認知意味論の知見をオブジェクト指向に適用すると…


役割場によるパターン記述例


役割場の構造と重ね合わせ


役割場の重ね合わせ例


MVCによる役割場の実現方針


UML

最新モデリング動向の見取り図

経営組織づくり

製造業モノづくり

概念的・戦略技術概念的・戦略技術

具体的・実現技術具体的・実現技術

BMBM：ビジネスモデリング：ビジネスモデリングSESE：システム：システム

エンジニアリングエンジニアリングSysML

UML for BMBPMN

UML

SOASOA：サービス指向：サービス指向

アーキテクチャアーキテクチャ組み込み組み込みリアルタイム設計リアルタイム設計

仮想化技術（ヴァーチャル化）

形式手法形式手法

DSL

MDDMDD：モデル駆動開発

SoftwareFactory

EAEA：エンタープライズ：エンタープライズ

アーキテクチャアーキテクチャ

PLEPLE：プロダクトライン：プロダクトライン

エンジニアリングエンジニアリング

MARTE

システム環境Ontology ビジネス環境Ontology


４＋１４＋１views of Software Engineering


ThingsThings

Persons/AffairsPersons/Affairs

ProblemProblem SolutionSolution

AgileAgileProcessProcess

Product LineProduct LineSoftwareSoftware

EngineeringEngineering

ProductProduct

ProjectProjectPeoplePeople

DomainDomain

ArchitectureArchitecture

ProcessProcess

ModelModel

ServiceService

DSLDSL

Dynamic Language

Formal Method

Meta/generative

仮想化/ Cloudcomputing

SE Education

Value oriented SE

Contract/Estimations

Problem Frame

Problem Engineering

2010.11.2

65

問題解決の手法複雑な対象の管理の方法論

Divide and Conquer 分割分割して解決せよ

Name and Conquer 名前名前を付けて解決せよ

Abstract and Conquer 抽象抽象化して解決せよ

Exemplify and Check 実例実例で検証せよ

Visualize and Collaborate 可視可視化して共働せよ


66

モデリングは可視化による問題解決「機械の動作」から「人間の思考」に近づく道程

Bit列記号手続きモジュール概念場?

機械語

アセンブラ

FORTRANCOBOL

(手続き型)

C(構造化)

AdaModula‐２

(ﾓｼﾞｭｰﾙ指向)

C++Java、C#

(ｵﾌﾞｼﾞｪｸﾄ指向)

C++Java、C#

(ｵﾌﾞｼﾞｪｸﾄ指向)

Next？

010011011110010010

NameName&Conq

DivideDivide&Conq UMLUML,OOAD

Usecase,MDA,Aspect,…

AbstractAbstract&Conq

VisualizeVisualize&ConqAdvanced

DivideDivide&Conq


67

知識の原則：UMLやSysMLの意図を理解して使う

UML、SysMLはコミュニケーションの手段自然言語と同じく「言葉」の一種

「誰に何を伝えたいのか」をいつも意識する

UMLやSysMLはオブジェクト指向モデル UMLと一緒にオブジェクト指向の言語と概念の勉強を

必ず具体例でオブジェクト（インスタンス）を意識してモデルを描いてみる

日本語の代わりにUMLやSysMLを使う訓練

具体例をオブジェクト図で表わしてみるクセを

身近な状況とUMLモデルとメモリ構造がマッピングできるように


68

知識の原則：UMLモデルの目的を考えて使うUMLモデルの目的現状モデル-理想モデル，要求-分析-設計モデル要求を表わす，構造を表わす，振舞いを表わす概念レベル，仕様レベル，実装レベル

UMLモデルの３つの表現レベルの使い分けスケッチ，設計図面，超プログラミング言語

概念レベル：スケッチとしてのUML クライアントやチームとの実質的コミュニケーション優先

仕様レベル：設計図面としてのUML メタモデルにもとづく正確なシステム仕様の文書化

実装レベル：超プログラミング言語としてのUML グラフィカルなプログラミング言語として（？？？）


69

UML/SysMLと可視化・合意形成プロセス

ビジネスビジネス

ITIT

業務業務ii

システムシステムアーキテクチャアーキテクチャ

ビジネスビジネスモデリングモデリング（要求開発）（要求開発）

ビジョン・ビジネスゴール

EAポリシー

業務プロセス

概念モデル非機能要求

本質ユースケース

システムユースケース

ビジネスビジネスアーキテクチャアーキテクチャ

戦略コンサル戦略コンサル

システム開発システム開発

エンタープライズエンタープライズアーキテクチャアーキテクチャ（戦略開発）（戦略開発）合意合意

プロセスプロセス

アーキテクチャアーキテクチャ

プロセス局面プロセス局面

UML/SyML/MDD

UML/EA

UML/BusinessModeling


まとめ：

「守破離」プロセスとモデリング

守ｼｭ・まもる自分の師匠の教え，型を守り，習熟する

破ハ・やぶる他の流派の教えを請い，ともに習熟する

離リ・はなる既存流派に囚われず，自分なりの新たな流派を起こす


UML/パタンで導入

DSL/MDD実践

形式手法・独自手法

まとめ：これからのSWエンジニア像

たとえば，豆蔵の試み３つのサービス：OO技術とSWエンジニアリングの

①教育教育②メンタリングメンタリング③開発コンサルティング開発コンサルティング

３つのテーマ： ①ITIT技術技術②設計とアーキテクチャ設計とアーキテクチャ③プロセスと組織プロセスと組織

３つの価値：新世代のエンジニア[1]職人職人としての技術力(総合的なエンジニアリング)

[2]芸人芸人としての機敏さ (アジャイルマインド：)

[3]座長座長としての統率力(リーダーとファシリテータ)

そのすべての中核に：モデルによるコミュニケーションモデルによるコミュニケーション

日本の産業界を活性化する武器は：見える化と協働見える化と協働のためのモデリング

ビジネスとＩＴの連動ビジネスとＩＴの連動によるアジャイル経営プロセス

理論的かつ実践的理論的かつ実践的なソフトウェアエンジニアリング2010.11.271 Hanyuda Eiiti，Mamezou

オブジェクト指向モデリング 技術の現在と未来9 hanyuda eiiti，mamezou 2010.11.2...

Documents

オブジェクト指向モデリング技術の現在と未来9 hanyuda eiiti，mamezou 2010.11.2...