コンポーネントベースモデリングによるsoaの実現 ·...

© Hitachi, Ltd. 2008. All rights reserved.

株式会社

日立製作所　ソフトウェア事業部

第2AP基盤ソフト設計部

2008/09/17

浜口　弘志

コンポーネントベースモデリングによるSOAの実現


１.SOAにおけるコンポーネント

２.MDAによるコンポーネントベースモデリング概要

３.業務事例

４.ビジネスプロセス設計とサービス設計の事例

５.日立が提供するSOA製品群

６.まとめ

Contents


１.SOAにおけるコンポーネント

１.１　SOAとは１.２　ビジネスプロセス設計とサービス設計１.３　SOAにおけるサービスとコンポーネントの関係１.４　業務機能コンポーネントとシステム機能

　　　コンポーネントの事例

1

3© Hitachi, Ltd. 2008. All rights reserved.

業務処理ＡＰ

業務処理ＡＰ

クライアント

サービスＡ

サービスＡ

サービス連携基盤

サービスリクエスタ


◎→□→□→□→●ビジネスプロセス

◎→□→□→□→●ビジネスプロセス

クライアント（Webブラウザ）ばかりでなくサービス自体が他のサービスを呼出すサービスリクエスタとなることもある

サービス連携基盤は、ESB

（Enterprise Service Bus）とも

呼ばれる

サーバ

各サービスとビジネスプロセスは同一ノードでも別ノードでも自由に配置することができる

ビジネスプロセスは、サービスの実行順序や実行条件を制御して、一連の業務処理を実現(BPELで記述)

一連の業務処理を複数の「サービス」に分解し、それを「ビジネスプロセス」として

連携させるアーキテクチャ

SOA（Service Oriented Architecture）とは

サービスＢ

サービスＢ

サービスＣ

サービスＣ

サービスは互いに独立して個々の業務ステップに対応した処理を行う

SOAとは１-１．


サービスＡ

サービスＡ

サービスＢ

サービスＢ

サービスＣ

サービスＣ

・・・

ビジネスプロセス

受注受注受付

在庫引当

製造手配

出荷指示

与信

見積

顧客受注係

受注を処理する注文する

BPEL実装

ビジネスプロセスモデリング

コンポーネントベースモデリング

　Java .NETなどでの実装

コンポーネント

ビジネスプロセス設計

サービス設計(コンポーネント設計)

ビジネスプロセス設計とサービス設計１-２．


システム機能コンポーネントシステム機能コンポーネント

ＡＰ開発のための共通部品　例：案件登録/更新/削除、製品情報検索、共通計算処理、帳票出力　etc

業務機能コンポーネント業務機能コンポーネント

業務処理を構成する最小単位　例：見積依頼受付、見積回答作成、見積　　　書出力、etc

ビジネスコンポーネントビジネスコンポーネント

一つのまとまった業務処理　例：見積り、受注、与信、輸出管理、etc

コンポ１

コンポ１

コンポ２

コンポ２

コンポ３

コンポ３

コンポ４

コンポ４

コンポ５

コンポ５

サービスＡ

サービスＡ

複合サービス

◎→□→□→□→●プロセス連携

◎→□→□→□→●プロセス連携

サービスＢ

サービスＢ

サービスＣ

サービスＣ



→データ連携

→データ連携

※　複合サービスの幾つかを更に連携させるビジネスプロセス

も存在する

※　レガシーＡＰも一つのサービスであり、対象のサービス単位

　　はそのＡＰのI/Fと考えることが出来る

SOAにおけるサービスとコンポーネントの関係１-３．


システム機能Ｃｏｍｐｏｎｅｎｔ

Excel入出力帳票 SVF生成 CSV入出力

文字列変換フォーマット/コード

ファイル(ZIP)

認証認証ロール管理

EBS連携

DB制御

ストアードプロシジャ管理

連結情報アクセス

データアクセス

ログ出力ｼｽﾃﾑ

管理

メッセージ出力

データ集配信

操作ファイル

アップロード/ダウンロード

メール送信

採番管理業務カレンダー管理

共通計算管理

入庫

棚卸

出庫

業務機能Ｃｏｍｐｏｎｅｎｔ

出荷指示

受注受付

与信

売上計上

在庫引当

検収・・・

・・・

業務機能コンポーネントとシステム機能コンポーネントの事例１-４．


２.MDAによるコンポーネントベースモデリング

２.１　MDAの概要２.２　コンポーネントベースモデリングの特徴２.３　ビジネスプロセス設計とサービス設計２.４　サービス設計２.５　ビジネスプロセス設計

2


MDAの概要２-１．

ＰＳＭ

ビジネスプロセスビジネスエンティティビジネスイベントビジネスルール

ＣＩＭ・ＰＩＭ

　MDA （ModelDrivenArchitecture）とは、分析モデルと設計モデルを分離、それぞれ独立した

　UMLベースのモデルを作成し、上位の工程から下位の工程へとモデルを引き継ぎ、　システムの機能や構造を詳細化していく開発アーキテクチャである。

　プラットフォーム決定時、分析モデルを特定の実装技術にマッピングすることで、設計モデルを作成する。

Ｊ２ＥＥ

.ＮＥＴ

・・・

アーキテクチャ

プログラムソース分析モデルマッピングルール設計モデル

実装技術

ＣＩＭ（Ｃｏｍｐｕｔａｔｉｏｎ－Ｉｎｄｅｐｅｎｄｅｎｔ

Ｍｏｄｅｌ）ＰＩＭ（Ｐｌａｔｆｏｒｍ－Ｉｎｄｅｐｅｎｄｅｎｔ

Ｍｏｄｅｌ）実装技術やプラットフォームに依存しないモデル（ビジネスロジック）

ＰＳＭ（Ｐｌａｔｆｏｒｍ－Ｓｐｅｃｉｆｉｃ

Ｍｏｄｅｌ）特定の実装技術やプラットフォームに依存したモデル

ＰＩＭの情報を特定のミドルウェア上にど

のようにマッピングするかを定義したもの

下流設計ツール

（uCosminexus Service Architect）

上流モデリングツール

（Pattern Weaver）


膨大なユースケース膨大なクラスと複雑な関連コンポーネントの切り出しが困難になる

モデリングの段階からシステム化範囲を分割

複数のシンプルなクラス図コンポ

ー

ネ

ント

ベー

ス

一般的な手法

コンポーネントベースモデリングの特徴２-２．


ビジネスプロセス設計とサービス設計２-３．

コンポーネント設計コンサルテーションＪａｖａテクニカルコンサルテーション

①開発対象業務の整理

②ビジネスプロセスの分析

③システム化範囲の決定

④機能要件の分析

⑤機能要件の詳細分析

⑥システム内部の情報分析

⑧システム内部の振舞分析

⑦オブジェクトの状態遷移分析

⑨論理クラス図

⑩論理シーケンス図

⑪リクエストマッピング

⑫ＤＢマッピング

情報システム部門（上流設計者）上流設計者、実装者

要求分析(ＰＩＭ) システム分析(ＰＩＭ) システム設計(ＰＳＭ) 実装・テスト

実装者

アーキテクチャ設計

画面／帳票設計

ＤＢ設計

⑬実装クラス図

⑯テスト仕様

⑭実装シーケンス図

⑰単体テスト

⑮実装

⑱連動テスト

業務主管部門等参画部署

イテレーション

非機能要件定義

用語辞書の作成、メンテナンス

標準化

業務分析(ＣＩＭ)






サービス設計２-４．

要件の整理を行い、

サービスを見出す

サービスの基本設計

を行う

サービスの詳細設計を行うサービスを実装する

①要件定義 ②基本設計 ④詳細設計 ⑤実装　

信用調査係

与信を行う

受注係

見積り内容を確認する

見積りを行う

顧客

見積りを依頼する

見積アクティビティ図act

審査管理（ EX-MS）

窓口担当

ローン審査を行う (001 ) 審査を実行する(01 )

審査結果を照会する(002 )

include

･･･

審査結果を取得する(01 )

include

審査結果を登録する(02 )include

審査管理（ EX-MS）　

Function

ローン審査　

+ ローン審査を行う (審査依頼) : 審査結果

Function

審査結果照会

+ 審査結果を照会する (照会条件) : 照会結果

審査実行（ EX-DAO）

Function

審査実行

+ ローン審査を実行する (審査依頼) : 審査結果

DataSource

審査結果登録

+ 審査結果を登録する (審査結果)

DataSource

審査結果取得

+ 審査結果を取得する (検索条件) : 照会結果

- - - - - - - - - - -

- - - - - - - - - - -

- - - - - - - - - - -

- - - - - - - - - - - - - - - -

-- - - - - - - - - - -

- - - - - - - - - - -

- - - - - - - - - - -

- - - - - - - - - - -

- - - - - - - - - - - - - - - -

-- - - - - - - - - - -

- - - - - - - - - - -

- - - - - - - - - - -

- - - - - - - - - - -

- - - - - - - - - - - - - - - -

-- - - - - - - - - - -

①要件定義フェーズ：上流モデリングツールで、

As-Is業務の問題点や要件からTo-Be業務を分析し、サービスを見出す。

②基本設計フェーズ：上流モデリングツールで、サービスの機能詳細と機能構造を定義。

　マッピング：上流モデリングツールの成果物を詳細設計以降のアーキテクチャに合わせて変更。　

③詳細設計フェーズ：下流設計ツールで、サービスの詳細設計。

④実装フェーズ：下流設計ツールで、サービスを実装。

アーキテクチャの適用

func.ExMsShinsaKanri

Interface

ExmsLoanSh in saIF

+ exDoLoanShinsa (shinsaIrai) : String+ exDoLoanShinsaShokai (kensakuJyouken) : List

com.dao.exDaoLoanShinsa

Function

ExmsLoanSh insa

+ exDoLoanShinsa (shinsaIrai) : shinsaKekka

Function

ExmsdoLoanSh insa

+ exDoLoanShinsa (shinsaIrai) : shinsaKekka

com.dao.exDomShinsaJikko

Function

ExmsdoKekkaSyoukai

+ exDoKekkaSyoukai (kensakuJyouken) : List

Interface

ExmsLoanSh insaJikko IF

+ exDoLoanShinsa (shinsaIrai) : String

Interface

ExmsLoanSh insaDao IF

+ exGetLoanShinsa (shinsaKekka)+ exInsertLoanShinsaShokai (kensakuJyouken) : List

③マッピング


ビジネスプロセス設計２-５．

①要件定義フェーズ：上流モデリングツールで、

To-Be業務と見出したサービスをもとに、ビジネスプロセスを定義。

②基本設計フェーズ：上流モデリングツールで、ビジネスプロセスの詳細を定義。

　マッピング：上流モデリングツールでBPELを作成し、下流設計ツールでインポート。

③詳細設計フェーズ：下流設計ツールで、サービス呼び出しの詳細を定義。

④実装フェーズ：下流設計ツールで、サービス間の連携を定義。

信用調査係

与信を行う

受注係

見積り内容を確認する

見積りを行う

顧客

見積りを依頼する

見積アクティビティ図act

receive見積依頼情報受付

見積内容確認invoke

reply見積結果通知

process受注

与信invoke

見積りinvoke

通知情報生成assign

<copy><from/><to/></copy>

見積BPELact

要件の整理を行い、

ビジネスプロセスを

定義する

呼び出すサービスを

決定する

サービス呼び出しの

詳細を定義する

サービス間の

連携を定義する





③マッピング

ツールによる連携

①要件定義 ②基本設計 ④詳細設計 ⑤実装　


３.業務事例

３.１　例題：ローン審査（現状の業務イメージ）

３.２　例題：ローン審査（将来の業務イメージ）

3


③

審査結果

審査依頼

例題：ローン審査（現状の業務イメージ）３-１．

顧客

■改善前のローン審査（仮審査）業務概要

担当窓口信用情報

管理システム

審査部門

既存システムで検索

（社内ブラックリスト、返済履歴、等）

氏名・生年月日

年収

融資希望金額

現在の借入金　等

融資の可・不可

（融資可の場合は

本審査の依頼）

社内審査基準をもとに

ローン審査を実行する

①顧客は担当窓口にローン審査を依頼をする。

②担当窓口は審査部門にローン審査を申請をする。

③審査部門はシステムに顧客情報を入力し、

　信用情報を検索する。

④審査部門はローン審査を行う。

⑤審査部門は担当窓口に審査結果を通知する。

⑥担当窓口は顧客に審査結果を通知する。

① ②

⑤

信用情報

⑥

審査結果④

審査部門を経由せずにローン

審査を行うようにしたい

　→業務効率向上

信用情報の検索とローン審査

をワンストップで行いたい

　→業務効率向上


信用情報検索サービス

審査依頼受付

信用情報検索

ローン審査

応答

ローン審査BPESB（Enterprise Service Bus）

信用情報管理システム信用情報DB信用情報DB

サービスアダプタ

TP１アダプタ

ローン審査サービス

サービス実行サーバ

DBサーバ

プロセス統合基盤実行サーバ

サービス実行サーバ（レガシー　システム）

リクエスタシステム実行サーバ

リクエスタ

例題：ローン審査（将来の業務イメージ）４-６．

担当窓口が

審査を実施

■改善後のローン審査（仮審査）業務概要

①顧客は担当窓口にローン審査を依頼する。

②担当窓口は顧客情報を入力し、ローン審査を

　実施する。

③担当窓口は顧客に審査結果を通知する。

顧客

③

①

審査結果

ワンストップで実行

②審査依頼審査結果

担当窓口


４. ビジネスプロセス設計とサービス設計の事例

４.１　要件定義フェーズ

４.２　基本設計フェーズ

４.３　マッピング

４.４　詳細設計フェーズ

４.５　実装フェーズ

４.６　システムの実現

4


②基本設計フェーズ

③マッピング④詳細設計　フェーズ

⑤実装　

フェーズ

申請者窓口担当

ローン審査を実施する仮審査を依頼する

融資を相談する融資の概要を決定する

[融資の概要に合意した場合]

[融資の概要に合意しなかった場合]

審査結果を通知する審査結果

顧客情報

要件定義フェーズ

■As-Is業務の問題点や要件からTo-Be業務を分析し、サービスを見出す（サービス設計）

４-１．

①要件定義

フェーズ

To-Beの分析信用情報管理（ EX-MA）


窓口担当


・･

ローン審査を行う (001 )

信用情報管理システム

信用情報を照会する(001 )

・・

窓口担当

サービスの分析



業務フローを

分析する

システム化範囲から

サービスを見出す


要件定義フェーズ

■To-Be業務と見出したサービスをもとに、ビジネスプロセスを定義（ビジネスプロセス設計）

４-１．



⑤実装　

フェーズ①要件定義

フェーズ

信用情報を照会する

ローン審査を行う

審査結果を返す

ローン審査を受け付ける

ビジネスプロセスの分析信用情報管理（ EX-MA）


窓口担当


・･




・・

窓口担当

サービスの分析業務フローと

サービス一覧から

ビジネスプロセスを

定義する



To-Beの分析申請者窓口担当

ローン審査を実施する仮審査を依頼する

融資を相談する融資の概要を決定する

[融資の概要に合意した場合]

[融資の概要に合意しなかった場合]

審査結果を通知する審査結果

顧客情報


①要件定義

フェーズ

基本設計フェーズ

■サービスの機能詳細と機能構造を定義（サービス設計）

４-２．


⑤実装　

フェーズ②基本設計フェーズ

審査管理（ EX-MS）　

Function

ローン審査　

+ ローン審査を行う (審査依頼) : 審査結果

Function

審査結果照会

+ 審査結果を照会する (照会条件) : 照会結果

審査実行（ EX-DAO）

Function

審査実行

+ ローン審査を実行する (審査依頼) : 審査結果

DataSource

審査結果登録

+ 審査結果を登録する (審査結果)

DataSource

審査結果取得

+ 審査結果を取得する (検索条件) : 照会結果

信用情報管理（ EX-MA）


窓口担当


・･




・・

窓口担当

サービスの分析

サービスの機能詳細分析

サービスの機能構造分析


窓口担当

ローン審査を行う (001 ) 審査を実行する(01 )


include

･･

審査結果を取得する(01 )

include

審査結果を登録する(02 )include

サービスの機能詳細

を定義する

サービスの機能構造

を定義する




①要件定義

フェーズ

基本設計フェーズ

■ビジネスプロセスの詳細を定義（ビジネスプロセス設計）

４-２．


⑤実装　

フェーズ

ビジネスプロセスの詳細分析


信用情報を照会するinvoke

ローン審査を行うinvoke

審査結果を返すreply

ローン審査を受け付けるreceive

process

ローン仮審査




ローン審査を受け付ける

ビジネスプロセスの分析

呼び出すサービス

を分析する






ローン審査を受け付ける受付アクション

信用情報検索サービスの呼び出し

ローン審査サービスの呼び出し※レガシーシステム

応答アクション

ビジネスプロセスの詳細分析

呼び出すサービス

の情報を設定する



①要件定義

フェーズ

マッピング

■上流モデリングツールでBPEL作成、下流設計ツールでインポート（ビジネスプロセス設計）

４-３．

④詳細設計　フェーズ

⑤実装　

フェーズ③マッピング

信用情報を照会するinvoke

ローン審査を行うinvoke

審査結果を返すreply

ローン審査を受け付けるreceive

process

ローン仮審査

ビジネスプロセスの詳細分析ビジネスプロセスの詳細定義

インポート

サービスの分類、名称、

オペレーションなど定義

した内容をインポート







①要件定義

フェーズ

詳細設計フェーズ

■サービス呼び出しの詳細を定義（ビジネスプロセス設計）

４-４．

③マッピング⑤実装　

フェーズ④詳細設計　フェーズ

ビジネスプロセスの詳細定義

サービス呼び出しの定義サービスの名称、

オペレーション、

入出力情報を定義





①要件定義

フェーズ

実装フェーズ

■サービス間の連携定義（ビジネスプロセス設計）

４-５．


⑤実装　

フェーズビジネスプロセスの詳細定義（データ連携の定義追加）

データ変換の定義

データ連携の

定義追加




システムの実現４-６．

山田太郎

■サンプルアプリケーションの実行画面

審査したい顧客を選択し

、詳細表示を依頼する

審査依頼情報を入力し、

審査を依頼する

審査結果

顧客一覧表示を

依頼する

ローン審査BPが

実行される


５．日立が提供するSOA製品群

5

５.１　日立が提供するSOAシステムの構築

５.２　統合システム構築基盤Cosminexus


上

流

設

計

者

上

流

設

計

者

受注入力受注入力

日立が提供するSOAシステムの構築５-１．

サービスアダプタ設計サービス設計

運

用

／

管

理

シ

ス

テ

ム

構

築

モ

デ

リ

ン

グ

業

務

・業務の改善

・問題点の調査

・要件の洗い出し

　　　　　　　　：

・ビジネスプロセス分析

・インターフェース分析

・コンポーネント分析

・データモデル分析

　　　　　　　　：

　　　　　　　　：

・インターフェース設計

・ビジネスプロセス定義

・サービスアダプタ設計

・サービス設計　・DB設計

　　　　　　　　：

・実行基盤による稼動

・運用基盤による運用・管理

　　　　　　　　：

　　　　　　　　：

業務主管部門

業務主管部門

実

装

者

実

装

者

運

用

／

管

理

者

運

用

／

管

理

者

在庫引当在庫引当

　プロセス統合

インタフェース統合

商品ＤＢ顧客ＤＢ

販売管理システム（オンライン）

ワークフローシステム

配送管理システム（オンライン）

物流システム（ＳａａＳ）

情報統合

経理システム（ＥＲＰパッケージ）

生産管理（メインフレーム）

　プロセス統合

インタフェース統合

商品ＤＢ顧客ＤＢ

販売管理システム（オンライン）

ワークフローシステム

配送管理システム（オンライン）

物流システム（ＳａａＳ）

情報統合

経理システム（ＥＲＰパッケージ）

生産管理（メインフレーム）

審査受注受付在庫引当出荷

分析モデリング

設計モデリング

受注入力

受注変更

在庫引当

入庫

受注入力

受注変更受注DAO

受注入力受注入力在庫引当在庫引当

ビジネスプロセス定義

審査受注受付在庫引当出荷

uCsominexus

Service Architect

コンポーネント

ベース（サービス）

モデリング

uCosminexus

Portal Framework、

uCsominexus

Service Platform、　　　　　

：

上流～下流までを

一貫して支援

ビジネスプロセス

モデリング

業務モデリング

審査依頼画面

提出

審査

顧客

社員組織受注受付

受注入力

受注変更

受注DAO

登録

更新

システムドキュメント審査管理システムテーブル仕様書

テーブル名審査管理マスタテーブルID Shin002

No. 項目名項目ID データ型バイト1 No id int 42 顧客名 retireDate varchar 403 審査結果 japaneseName int 54 審査依頼日 employeeNumber datetime 105 審査完了日 retireReason datetime 106 審査基準 lastUpdateDate datetime 10

DB設計

IF設計


環境設計

チューニング

構築手順

運用手順

トラブルシュート手順

システムパターンカタログ

処理方式設計

サイジング

提案・設計フェーズ

構築・運用フェーズ

設計手順・

製品適用ガイド

プロセス統合

情報統合

インタフェース統合 uCosminexus Portal Framework

uCosminexus Service PlatformuCosminexus Service Architect

　　　　　　　　　　　　　　　　　　　　

ワークフロー

　　　　　　　　　　　　　　　　　　　　

オンライン

uCosminexusApplication Server

OpenTP1開発ｺﾐｭﾆﾃｨMyEclipse

電子フォームワークフロー

uCosminexusInformation

Federator

DataStage/QualityStage

uCosminexusInformation

Replicator

統合サービスプラットフォーム

統合運用管理

パートナーソリューション/パッケージ

　　　　　　　　　　　　　　　　　　　　

オープンバッチ

uCosminexusBatch Job

Execution Server

　　　　　　　　　　　　　　　　　　　　

帳票印刷

ＥＵＲ　　　　　　　　　　　　　　　　　　　　DocumentBroker

コンテンツ管理

HiRDB

統合システム構築基盤Cosminexus　５-２．

多様な形態でのサービス統合・サービス構築を実現する基盤機能システム構築の羅針盤となる設計手順・製品適用ガイドを提供


６．まとめ

6


まとめ６．

SOAによるシステム構築では、その特徴として、業務を構成する要素をサービス化

し、業務をサービスの組み合わせで構成することで、全体最適なシステム構築が実

現できる。さらに、生産性や保守性の向上、分散開発が可能である。

これらを実現するためにはSOAに適した開発プロセスの適用が必要である。

開発プロセスの性質として

　・上流から業務視点のコンポーネント（サービス）を見出す

　・適切な粒度のサービス、ビジネスプロセスの定義

　・サービスから利用される共通機能の拡充

　・コンポーネント分割による分散開発


END

2008/09/17

浜口　弘志

コンポーネントベースモデリングによるSOAの実現

株式会社

日立製作所　ソフトウェア事業部

第2AP基盤ソフト設計部


《他社所有名称に対する表示》

・　Eclipse

は，開発ツールプロバイダのオープンコミュニティであるEclipse Foundation, Inc.

により構築された

　開発ツール統合のためのオープンプラットフォームです。

・　Java及びすべてのJava関連の商標及びロゴは，米国及びその他の国における米国Sun Microsystems,Inc.の商標

　または登録商標です。

・　JavaScriptは，米国及びその他の国における米国Sun Microsystems,Inc.の商標または登録商標です。

・　Microsoft® は，米国及びその他の国における米国

Microsoft Corp.の登録商標です。

・　OMG，CORBA，IIOP，UML，Unified Modeling Language，MDA，Model　Driven　Architectureは，

　Object Management Group Inc. の米国及びその他の国における登録商標または商標です。

その他記載の会社名、製品名は、それぞれの会社の商標もしくは登録商標です。

コンポーネントベースモデリングによるsoaの実現 ·...

Documents