UMTP モデリングフォーラム 2013

企業情報システムの早期アーキテクティングとモデリング2013年11月20日
情報システム総研

児玉公信

いきさつ
 去年のUMTPフォーラムのパネルディスカッション
 ポジション：早期アーキテクティングの考え方 システム思考 システムライフサイクルプロセス
 参照ドメインモデルによる施主要求の揺さぶり Enterprise Systemのアーキテクティング

 ディスカッション
 ドメインモデルの磨き方 知識レベルモデルの成り立ち
 フォークロアモデルを駆逐する
 モデルの検証
 モデラの育成
 モデリングとは何か– 組織学習– 質的アプローチ– “良さ（quality）”の本質
2

システムとソフトウエア
 JIS X0001 情報処理用語—基本用語 ソフトウエア
 情報処理システムのプログラム，手続き，規則及び関連文書の全体又は一部分

 情報システム 情報処理システムと，これに関連する人的資源，技術的資源，財的資源などの組織上の資源とからなり，情報を提供し配布するもの システムとは 「多数の構成要素が有機的な秩序を保ち，同一目的に向かって行動するもの」（JIS Z 8121）
 「相互に作用し合う要素の集合」で「オーガナイズされた全体」（ベルタランフィ，「一般システム理論」，1968）
 「オブジェクト間の関係を含むオブジェクトの集合（Fall & Fagen,1968）」だが，「それは観察者の視点・観点に依存する」（ワインバーグ，「一般システム理論入門」，1975）3基幹情報システムの再構築
 煙突システム 企業情報システムとしての連携の阻害
情報の重複・散在，作業のムダ，保守費の増大
情報の脱本質化

 再構築
 複雑さの整理：本質化 堅牢性と変更容易性の追求
A sys

B sys

C sys

AX

BX

CX

AY

BY

AZ

BZ

A

B

A xyz
CYZ

X

C

BC xyz

YZ
4

施主主導の情報システム再構築
 情報システムサイクル “良い”情報システムを目指す継続的な営み

 基幹システム刷新の真の施主は経営者
 CIO（施主）チーム
 業務設計（設計者）チーム
 アーキテクチャ（EA）チーム

 プロフェッショナルの参画
 アーキテクト支援
 設計者支援 モデラ支援
 施工者

施主

製品

使う・育てる

原要求

人工物

アーキテクト

設計者
要求

施工者
要求の理解

仕様
5

システムライフサイクル
 二つのライフサイクルプロセス
 JIS X0170:2004（ISO/IEC 15288:2008）
 JIS X0160:2012（ISO/IEC 12207:2008）
JIS X 0170：2004 (ISO/IEC 15288：2002) システムライフサイクルプロセス

プロジェクトプロセス
プロジェクト計画
期待
意志決定

プロジェクトアセスメント
リスク管理

プロジェクト制御

構成管理

情報管理

投資管理

テクニカルプロセス
利害関係者
要求定義

概念段階

製造段階

妥当性確認

Con
Ops

要求分析

開発段階

エンタプライズプロセス
エンタプライズ
環境管理

移行

方式設計

支援段階
保守

検証

Bus.
Rqmts

結合
Req.
Spec,

実装

利用段階
運用

実装物

廃棄段階
処分

効果

システムライフサイ
クルプロセス管理
資源管理
品質管理

合意プロセス取得
供給プロセスハードウエア制作

運用者教育訓練

ソフトウエア作成

JIS X 0160:2012
ソフトウェアライフサイクルプロセス

6

要求定義
 ISO/IEC/IEEE 29148-2011
 要求スコープの例

7

企業情報システムのガバナンス
 CIOの役割
 構築フェーズと執行フェーズ
 中長期的展望=都市計画 アーキテクチャによる統治
 全体最適とその指標
 持続可能な組織
アーキテクチャプログラムマネジメント

都市計画，
情報戦略立案

経営トップ

コミュニケーション

予算配分，流量制御
順序とタイミング
CIOチームアーキテクチャチーム
施主

アーキテクト
設計者

事業の長

業務機能の提供

利用者

管理者

顧客

施工者

システム構築フェーズ
運用・保守チーム

業務の執行フェーズ

8Zachmanフレームワーク
 建築学との出会い
 断片化された企業情報システムを系統だった分散化に移行する
 Zachman, “A framework for information systems architecture,”
IBM Systems Journal, Vol. 26(3), 1987

ライフサイクル

建築メタファ

ISドキュメント

データの記述プロセスの記述

ネットワークの記述

バブルチャート

スコープと目標

重要なエンティティの一覧

実施されるプロセスの一覧

営業拠点の一覧

建築家の製図（施主の表現）

ビジネスモデル

ER図機能フロー図

ロジスティックネットワー
ク

建築家の計画情報システムのモデル（建築家の表現）

データモデル

DFD

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

生産計画
技術のモデル（施工者の表現）

データ設計

構造チャートシステムアーキテクチャ

個別実施計画詳細記述（文脈外の表現）

データベーススキーマ

プログラム

ネットワークアーキテクチャ

建物

製品（情報システム）

データ機能

通信

9

Zachmanフレームワーク2
 5W1Hで拡張
 Enterprise Ontologyへ Sowa & Zachman, “Extending and formalizing the framework for
information systems architecture”, IBM Systems J., Vol. 31(3), 1992
データ（what）

機能
（how）

モデリングの観点
Peopleネットワーク（where）（who）

Time（when）

Motivation
(why）

視座

成果物

Planner

スコープ

重要なビジネ ビジネスプロ
ス事項の一覧 セスの一覧

Owner

企業モデル

ER図

Designer

システムモデル

データモデル DFD

分散システム
HIのアーキテ
プロセス構造 知識構造
アーキテクチクチャャBuilder

技術モデル

データ設計

構造チャートシステムアー 人と技術のイ
制御構造
キテクチャ
ンタフェース

知識設計

Subcontractor

コンポーネント

データベース
スキーマ

プログラム

ネットワークア セキュリティア タイミング定ーキテクチャ ーキテクチャ 義

知識定義

現物

稼働システム

データ機能

ネットワークプロセスフロー図

営業拠点の一組織の一覧
覧ビジネス事象 目標・戦略のの一覧
一覧

ロジスティック
組織図
ネットワーク

マスタスケジ
ュール

組織

事業計画

スケジュール 戦略

10

要求分析手法の比較
ISO15288

児玉Wiegers(2006）

施主
業務構想書（ConOps）

文書化

要求分析

要求アナリスト
ビジネス要求「もの・こと」分析
業務フロー図Customer-Performer

コンテキスト図
ユースケース（ビジネス）

機能の発明

フィーチャ記述アナリスト
要求のトローリング
スノーカードビジネス事象ビジネスユースケース

ユースケース（機能）

要求依存性行列ビジネスモデルテンプレートテンプレート

概念モデル

文書化

ビジネスアナリスト
要求決定
要求抽出
要求の調整と妥当性

要求の発明
仕様化

情報の発見

方式設計

Maciaszek（2001）

ステークホルダ
プロジェクトの方向づけ会議（Blast-off）

利害関係者
業務シナリオ
要求定義（原要求） 設計者

要求関連図
IEEE Std 1362
設計者
仕事の流れ

Volere(2006)

コンテクスト図
ユースケース（フィーチャ）ビジネスクラス図アーキテクト管理階層
階層間インタフェース

文書化
要求管理

ファンクションポイント 複数リリース

ファンクションポイント ファンクションポイント
要求のメタ管理変更管理， 要求追跡
11

問題解決
 問題解決におけるシステムアプローチ
 原因除去で問題が解決するとは考えない システムは問題も創発する
 問題はシステムの弱いところに表面化する システム内の要素は問題状況に抗えない（せいぜい改善） 全体最適を狙う

 システムを変えることで問題を転換する 目的を変える 要素間の関わり方（アクション）を変える
 レベレッジ
現状

現在のシステム理想

新しいシステム

問題構造を転換するプロセス
12

構想−原要求−仕事の設計 業務シナリオによる構想の記述
 新しいシステムをありありと描き出す 業務シナリオから原要求抽出 シナリオ分析

依頼合意

 M-GTAによる要求の構造 原要求分析：SysMLの要求図
 目的，要求，方法を分離
 要求の優先づけ

Customer
満足 要求を満たす仕事の設計 プロセス図：「もの・こと」分析
 終わりの状態／始めの状態
 次元の一致

Performer
実行

Medina-Mora, et al, "The Action Workflow Approach toWorkflow Management Technology," Proc. of CSCW 92,
pp1-10, 1992

 アクティビティ図：Customer-Performer
 対話の4象限
13

機能の設計−方式設計 仕事の達成を支援（enable）する機能の発明
 アクタがトリガする実世界での基本変換
 “システム”のレーンは設けない

 機能記述：ユースケース記述（要求レベル）
 ユースケースの目的は，その仕事の達成
 ユースケースシナリオは，その仕事のインスタンス

 方式設計 Enterprise Architecture 設計原則 システム分割の原則
 対話の構造 情報システムパタンランゲージ

 ドメインモデリング 参照モデル 揺さぶり会員図書館の職員［書名がわかっている］
文献を検索する《usecase》
1.蔵書を検索する《usecase》
2.貸出を記録する

書架に本を見つける
図書館の職員に貸出を申し出る

本［帯出許可前］

貸出の申し出を受ける
本を貸し出す本を受け取って退出する

本［帯出許可後］本の帯出許可をする

14

システム分割の指針
 管理階層と業務相に基づくシステム分割
 勘定系ドメインは，関心対象のライフサイクルを管理する
 セマンティクスの分離：ドメインごとのモデル，アンチ・ユビキタス言語

 ドメイン間の相互作用 対話の設計，非同期連携
管理レベル

維持

知識更新
（保守）

商流階層

報告

業務相

計画・実績

物流階層
金流階層

報告

計画・実績

操作階層

報告

計画・実績

報告相（情報系）

計画・実行相（勘定系）

管理対象

知識（売り方）知識（作り方）知識（手順）

知識相

リード

商い資源
資産

管理階層

知識生成
（開発）

ワーク

15

情報処理システムのマクロ構造例
 システム分割指針に沿ってサブシステムを設定
 ドメインモデルとユースケースのパッケージ よいモジュールの原則
 管理階層と業務相（coupling）
 機能強度（cohesion）

 インタフェースに命名 一方向の原則
 Observerパタン

 外部複雑性の制御
 契約のバリエーション
 契約条項の記述
 ルール形式

 商品のバリエーション
 製品のバリエーション
16

インタフェース設計
 対話のモデル
 KQMLによるメッセージ設計→XML/JSONにコーディング 疎結合高速メッセージング
 ESB（Enterprise Service Bus）
setCustomerOrder(:verb request:message-number nnnnnnnn:from 対外部
:to 案件受付:content(CO(--CustomerOrder--),number-of-records(nn),check-sum(nn)))
Finin, Fritzson, McKay, and McEntire: “KQML as an agent
communication Language,” Proceeding CIKM '94, p456-463, 199417

対話の構造 状態機械図
 拒否，中止，差し戻し 日本型の曖昧なCommitment
 1状態と3つの遷移を追加
A:ChangeRequest

1

A:Request

2

B:Promise3

A:Accept
B:Counter
A:Counter
B:Decline
A:Cancel

A:DeclineReport
A:Confirm
Expired3’

B:Report
Completion

4

A:Declare
Complete5

B:Cancel
A:Cancel

6

7
A:Cancel

A:Cancel
B:Cancel

8
Winograd, T.: A Language/Action Perspective on the
Design of Cooperative Work, HUMAN-COMPUTERINTERACTION, Vol.3, pp.3-30 (1987-1988)918

インタフェースのプロトコル トランザクションデータの受け渡し

19

システム間連携のモデル
 階層間は，Customer-Performerの関係とみなす
 一方向で細い参照 オーダに対する作業分解
 知識による計画展開

20

ドメイン駆動 システムの全体構造の仮説提示
 ドメイン構造の仮説提示 目的，仕事，機能の仮説
 蓄積されたドメイン知識
e.g. 生産管理のto-be，IEC 62264

 ドメインモデルの提示
 一般モデル より安定な初期モデル
 パタンの活用 一般モデル，類似モデルがある場合
 構想を支援する高速プロトタイピング
 たたき台 参照モデルがない場合
 ユースケースからモデリング21

勘定系ドメインモデルの要点
 時間の征服 Future Perfect 資源の近未来の状態
 計画と実績

累
積量 入庫

仕入滞留時間 事象の記録（フロー情報）
 学習サイクル よい計画を立てるための知識
 PDCA
予定が実績に塗り変わっていく様子

注文
在庫

出荷
期首

現在
実績

予定

在庫量時間

安全在庫

期首

現在
実績予定時間22

ドメインの一般モデル
 生産管理ドメインの一般モデル（CHARM3）
Cross Hierarchical Account=Resource Model v.3児玉公信，水野忠則，「少量多品種型生産管理システムの一般モデルCHARMの提案」，
情報処理学会論文誌，Vol. 49(2), 902-909, 2008

23

操作レベルと知識レベル
 生成ルールの外部化（Externalize Instantiation Rule）
 問題
インスタンス生成時の生成ルール（知識）が各クラスに散在するが変更も多く，ルールの総合的な意味が分からなくなる

 解決策
生成ルールをクラスから分離し，知識レベルに集約する
操作レベルのclientは，知識レベルに複数のインスタンス生成を委託する。知識レベルは生成ルールに従って操作レベルの各クラスのConstructorを順にCallbackする（たとえばVisitorパタン）
取引型

*

*

移動型

*

*

資源型

visit( )型型型

知識レベル
操作レベル

*

注文

*

取引
constructor( )accept( )*2..*移動constructor( )**資源constructor( )24操作階層での計画・実行相
 空間的距離の対策
 Supervisory Control 月面車を地球から安全に操作する
月面で判断・実行するものと，地球が判断・指示するものをリスクに応じて分割

 MES（製造実行システム）
 対上位：物流管理層のProxyまたはcache 対下位：機器の操作
HumanOperator
Display

Controller

HumanOperator
Display

Controller

HumanOperator
Display

ProxySensor

Actuator

Controller

SensorActuator

SensorActuator

Task

Task

Task

Manual Control

Supervisory Control

Full Automatic Control

25マイクロアーキテクチャ
 ユースケース実現のアーキテクチャ
 階層化とMVCパタン 必要に応じてApplication Façade（導出表の提供）

 フレームワークによる負荷分散
 スケールアウトの実現 機能ロジック部の独立実装レベル

ユーザインタフェース（V）

クライアントサイド

概念レベル

ユースケース（機能）ドメイン（関心対象）

機能ロジック（C） Application

フレームワークの境界Facade

ドメインのAPI

オブジェクトの集合（C, M）
O/Rマッピング

DBMSサーバサイド26

ドメインの先行実装
 早期アーキテクティング
 要求定義前に概念モデルがある できれば実装もあるとよい
 動かしてみる
 モデルの理解 フレームワークの前提
 クラウド利用
 オートスケールアウト
 バックアップ系の完備

 概念モデルを参照しての要求定義
 想定ビジネスプロセス，ユースケース
 業務シナリオによる概念モデルの揺さぶり 実ビジネスプロセス，ユースケースのあぶり出し
27

実装モデリング 型からクラスへ
 概念モデルに従う
 設計判断 オブジェクトの識別方法：OIDとコードの併用
 候補キー（ユニーク性）の解釈，参照の解決，データ型の決定
 型の内部属性化，下位型の実装

 メソッドの配置
 インタフェースの設計：Design by Contract
 APIの設計，制御の逆転
 ドメインリッチ化
c la s s 検 査 ・ 検 体 マ ネー ジ メン トク ラス図

【大工程】
1:集荷
2:仕分
3:検査
4:報告
5:物 流

 ORマッピング 非機能要求の作込み【事業所種別区分】
1:業務拠点2:施設
3:検査室

 性能，安全性 トランザクション管理【スケジューリング状態区分】
0:未
1:依頼中
2:済み

2013/5/24
・表示 用依頼 番号を追加
2013/5/30
・親作業番号を追加（検体マネジメントの場合は空文字が入る）

28【占有区分】
1:占有
2:移動
3:循環

前 0..1{なし}【作業区分】
1:物流
2:検査+ 計 画時刻 :String+ 計 画日 :String
3:在庫+ 指示先事業所識別 :S...
後*+ 実績開始時刻 :String{なし}+ 実績開始日 :String+ 実績終了時刻 :String+ 実績終了日 :String+ 取引条件 :String+ 取引条件内容 :String
2013/6/7+ 取引条件名 :String・クラス追加+ 取引単位識別 :String+ 集荷先施設識別 :String 工程単位に送信しない場合+ 所要時間 :BigDecimal
は工程に*をセットする。
+ 前注文番号 :String+ 対象検体識別 :String+ 大工程 :String+ 大工程識別 :String+ 大工程種別 :int*+ 単体項目 :String+ 担当事業所識別 :String+ 注文時刻 :String+ 注文日 :String+ 分離分注先検体識別 ...
+ 予定開始時刻 :String«DomainClass»+ 予定開始日 :String
PDP送 信 先+ 予定終了時刻 :String+ 予定終了日 :String+ 送信先コード :String+ 展開条件 :String+ 処 理種別ID :String+ 表示用依頼 番号 :String + メッセージID :String+ 親注文番号 :String0..1 *«pk»+ スケジューリング状 態...
+ 担当事業所識別 :St... {な {+ 注文メモ欄 :String
し} な+ 工程 :String+ 受付日 :Stringし+ 送信元コード :String+ 受付時刻 :String}+ 実績フラグ :boolean+ メモ欄 :String+ 元作業番号 :String+ 受付拠点事業所識別 ...
«pk»
1..*+ 依頼番号 :String{な+ 注文番号 :Stringし}+ add作業(Map) :作業+ find注文ByAnyForスケ...
+ スケジューリングする(...
+ 依頼マネジメントに送...
注文+ 計上時刻 :String+ 計上日 :String+ 工程 :String+ 工程識別 :String+ 工程種別 :int+ 作業開始時刻 :String+ 作業開始日 :String+ 作業区分 :String+ 作業型識別 :String+ 作業終了時刻 :String+ 作業終了日 :String+ 所要時間 :BigDecimal+ 物流注文番号 :String+ 作業開始日時 :String+ 作業終了日時 :String+ 親工程 :String+ 前作業 番号 :String+ 前工程識別 :String+ 単体項目識別 :String+ 測定グループ :String+ 集約可能フラグ :boolean+ 前作業型識別 :String+ 次作業型識別 :String+ 実施可能フラグ :boolean+ 完了フラグ :boolean«pk»+ 依頼番号 :String+ 作業番号 :String+ 実績フラグ :boolean+ 注文番号 :String+++++++++++add移動(Map) :移動
find作業By注文Key(Map) :Co...
find作業By日付(Map) :Collec...
find作業For検体進捗照会(Ma...
has実績() :boolean
sub移動(Map) :void
スケジューリングする(Map) :...
ラボへの検体到着の取引実...
荷造の取引実績を記録する(...
拠点への検体到着の取引実...
血清分離の取引実績を記録...

/収容する容器 0..1{なし}
移動

予定 0..1{なし}

作業
実績 0..1{なし}

1*+ 位置 :String+ 資源保有識別 :String+ 実績存在フラグ :boolean+ 収納先移動 番号 :String+ 状態 :String+ 数 :BigDecimal+ 占有区分 :String+ 量 :BigDecimal+ 作業開始日 :String+ 作業開始時刻 :String+ 作業開始日時 :String+ 作業終了日 :String+ 作業終了時刻 :String+ 作業終了日時 :String+ 資源管理識別 :String«pk»+ 依頼 番号 :String+ 移動 番号 :String+ 作業 番号 :String+ 実績フラグ :boolean+ 注文 番号 :String++++++++++++++++++++

find移動By作業Key(Map) :Collection
find移動By資源保有Key(Map) :Coll...
has実績() :boolean
ラボへの検体到着の移動実績を記...
荷造の移動実績を記録する(Map) :...
拠点への検体到着の移動実績を記...
血清分離の移動実績を記録する(M...
検査実績の移動実績を記録する(M...
検体受領の移動実績を記録する(M...
仕上実績の移動実績を記録する(M...
使用量を算出する() :Map
収納する(移動) :void
前処 理の移動実績を記録する(Map)...
内容を取得する() :Collection
容器を取得する() :移動
findEntryByDate(Map) :Collection
find移動Join作業(Map) :Collection
find移動By引当(Map) :Collection
findEntryByRequestNo(Map) :Collec...
子検体に紐付ける(String) :void

容器 0..1{なし}*

資源保有{abstract}

内容 *{なし}
内容 *{なし}

1+ 群体識別 :String+ 個体フラグ :boolean+ 材料識別 :String+ 初期在庫量 :BigDecimal+ 消 滅時刻 :String+ 消 滅日 :String+ 生 成時刻 :String+ 生 成日 :String+ 資源管理識別 :String«pk»+ 資源保有識別 :String++++++++

1
群体 0..1{なし}

findByPrimaryKeyMapForUpd...
is群体() :boolean
個体 *群体を取得する() :資源保有{なし}
個体を取得する() :Collection
在庫を引き当てる(Map) :Map 1
容器を取得する() :資源保有
findBy資源保有識別(Map) :C...
find資源保有By移動(Map) :C...

ユースケースと型の関係確認
 型と機能の整合性をチェックする 機能の漏れを見つける オブジェクト生成機能（CRUDの完成）

 DFDまたはBCE図

1

顧客

*

 DFDはレベル0，分解しない または（入出力の方向を明示した）BCE図

注文

*1

商品

 1プロセス（コントロールオブジェクト）に1アクタ 1プロセスに1以上のデータストア（エンティティオブジェクト=型）
 プロセス間のデータフローは禁止
注文を受ける

受付係《usecase》
注文を記録する注文を受ける：注文

注文を記録する
受付係

顧客

注文

商品

29

設計原理の適用
 パタンランゲージとEnterprise Architecture 設計原則の記述形式としてのパタン
 EAの運営
 計画評議会=アーキテクチャチーム
 設計原則（パタン）の維持，遵守監視 学習サイクル［続ける］

そのドメインのパタンランゲージを作る

計画
評
議会

《define》《modify》《feedback》

パタンランゲージ《refer》

計画ランゲージ
プロ
ジ
ェ
ク
ト

語彙

語彙

利害関係者
要求定義

ConOps

30

利用者

期待

デザイン
コード

要求分析

Sys
Rqmts

デザイン
コード

方式設計

Basic
Design

製造段階

実装物

利用段階

成果