Contents 1. SOA とコンポーネントの事例 2. コンポーネントベースモデリングの背景 3. コンポーネントベースモデリングの事例 4. プロジェクト推進のポイント

Transcription

1 システム開発プロジェクト現場におけるモデリングの実際 ( 株 ) 日立製作所ソフトウェア事業部チーフアーキテクト桐越信一

2 Contents 1. SOA とコンポーネントの事例 2. コンポーネントベースモデリングの背景 3. コンポーネントベースモデリングの事例 4. プロジェクト推進のポイント

3 Contents 1. SOA とコンポーネントの事例 2. コンポーネントベースモデリングの背景 3. コンポーネントベースモデリングの事例 4. プロジェクト推進のポイント

4 1-1 ポイント 一般的に定義されている SOA とは SOA 技術とは サービスの組合せ でシステムを構築すること アーキテクチャとして ( 分散処理 業務の部品化 ) アプローチとして ( 業務プロセスの可視化 サービスの再利用 ) サービスとは? 外部から標準化された手順によって呼び出せる一連のソフトウェア群 (= コンポーネント ) 単体で人間にとって意味のある単位の機能を有するソフトウェア群 与信 一まとまりの機能単位 ( サービス ) 標準化されたインタフェース アプリケーション自体に他のソフトウェアとの連携機能を持たせたものといえる 組合せとは? 業務に合せて必要なサービスを緩やかに結合することサービス同士は連携基盤で柔軟なシステムを構築 (ESB) 経由で接続される 業務をサービスの集合としてとらえることで プロセスの可視化を実現 サービスの部品化を進めることで 再利用を促進在庫引当出荷指示在庫出庫 サービス として分解された一連の業務処理を組合せて 業務プロセス全体を構築する考え方が SOA Enterprise Service Bus (ESB) ビジネスプロセスとサービス接続制御

5 1-2 SOA におけるサービスとコンポーネントの関係 システム機能コンポーネント AP 開発のための共通部品例 : 案件登録 / 更新 / 削除 製品情報検索 共通計算処理 帳票出力 etc コンポ 1 コンポ 2 コンポ 3 コンポ 4 コンポ 5 業務機能コンポーネント 業務処理を構成する最小単位例 : 見積依頼受付 見積回答作成 見積書出力 etc サービス A サービス B サービス C ビジネスコンポーネント 一つのまとまった業務処理例 : 見積り 受注 与信 輸出管理 etc プロセス連携プロセス連携複合サービス データ連携データ連携 複合サービスの幾つかを更に連携させるビジネスプロセスも存在する レガシー AP も一つのサービスであり 対象のサービス単位はその AP の I/F と考えることが出来る サービスリクエスタ

6 1-3 業務機能とシステム機能コンポーネントの事例 業務機能 Component 与信 在庫引当 出荷指示 入庫 出庫 受注受付 売上計上 棚卸 検収 業務 採番管理 カレンダー管理 共通計算管理 帳票 Excel 入出力 SVF 生成 CSV 入出力 DB 制御 EBS 連携 データアクセス ストアードプロシジャ管理 連結情報アクセス 変換 文字列 フォーマット / コード ファイル (ZIP) 認証 認証 ロール管理 システム管理 ログ出力 メッセージ出力 データ集配信 操作 ファイルアップロード / ダウンロード メール送信 システム機能 Component

7 1-4 SOA とコンポーネント化の事例 ( サービス組立 ) 基幹ビジネスプロセス SOA ビジネスプロセス 受付出荷指示出荷 EDI 受信データ組立運賃計算送品状作成 顧客 A サービス パラメタ a データ組立コンポーネント 運賃計算コンポーネント 例外クラス 1 送品状作成コンポーネント 1 共通クラス 共通クラス 共通クラス 顧客 B サービス パラメタ b 例外クラス 2 送品状作成コンポーネント 2 共通クラス

8 1-5 SOA とコンポーネント化 ( 適合性事例 ) 業務処理 SOA 適合性 コンポーネント化 のメリット 備考 トランザクション系 共通処理 コンポーネント化を行なうことでパラメタ駆動による処理が可能な部分が多い さらに 顧客ごとに異なる処理を組み合わせる部分があるため コンポーネント化を行い サービスという単位で組み換えを行なうことで これらの対応が容易になる トランザクション系個別処理 個別部分はコンポーネント化しても 他からの流用が無いため 効果が望めない 照会系処理 印刷系処理 マスタメンテナンス コンポーネントのデータアクセス部分は全て共用可能 情報などを公開することを考えると アクセス権に応じたサービスの組み換えが必要となり これらに対応可能 コンポーネントの共用は全面的に可能 サービスという側面で考えると どういった印刷をするかを判断し 組み立てる構造にできるため この部分でのメリットがある データアクセス部分は全て共用可能 メンテナンス系は使用者が限られ サービスとして組み替えるニーズは少ないはずであり SOAとしての適合は対象外

9 1-6 AsIs ビジネスプロセス SOA とコンポーネント化の事例 ( サービス組替え ) 受注輸出審査出荷止め出荷指示出荷 AsIs サービス構成 受注受付コンポーネント 輸出審査コンポーネント 出荷止め管理コンポーネント ToBe ビジネスプロセス 輸出審査 出荷止め 受注出荷指示出荷 ToBe サービス構成 輸出審査コンポーネント 出荷止め管理コンポーネント 受注受付コンポーネント

10 1-7 SOA における設計アプローチ ビジネスプロセスモデリング 顧客 受注係 ビジネスプロセス設計 BPEL 実装 注文する 受注を処理する ビジネスプロセス コンポーネントベースモデリング 与信見積受注受付受注在庫引当製造手配出荷指示 サービス A コンポーネント サービス設計 ( コンポーネント設計 ) サービス B Java.NET などでの実装 サービス C

11 Contents 1. SOA とコンポーネントの事例 2. コンポーネントベースモデリングの背景 3. コンポーネントベースモデリングの事例 4. プロジェクト推進のポイント

12 2-1 参画プロジェクトでの反省 年 1999 年 ~ 2000 年 適用技術 Java UML( クラス図のみ ) 対象システム 他社 ( 製造業 )SCM システム 反省点 保守性 : プログラム構造がバラバラ生産性 : 開発効率が従来と比べ それほど上がらない 年 適用技術 対象システム 2001 年 Java UML( クラス図のみ ) MVC フレームワーク コンポーネント適用 反省点もっと抜本的に低減できないのか? コンポーネント化はうまくいったのか? 自社 CRM システム 保守性 : プログラム構造の統一が可能生産性 : 設計工程 3 割減コーディング工程 1 割減テスト工程 2 割減

13 2-2 プロジェクトでの適用コンポーネント検証 MVC フレームワーク提供の適用コンポーネント 提供コンポーネント 入力チェック 内容 定義条件に基づき ユーザの入力内容をチェック 入力画面における文字サイズ 数字項目のチェックなどに利用 RDB アクセス HTML テンプレート RDB をオブジェクトベースでアクセスする 拡張 HTML で記述されたテンプレートファイルで動的画面生成 開発コンポーネント ( 代表例 ) 開発コンポーネント 内容 システム機能的なコンポーネントが中心 ユーザ認証 HiRDBアクセスファイル操作入力データ変換リストボックス展開 ディレクトリサーバ (LDAP) からのユーザ照会と情報取得 cpersistenceのhirdbアクセスラッパ WebAPに対し ローカルファイルのアップロード ダウンロード 業務用ロジックへのファイルインタフェースの提供コード変換 日付変換など業務 AP 開発に必要な操作の提供リストボックスへの外部パラメタからのデータ展開

14 2-3 プロジェクトでの開発プロセス検証 フレームワークに沿った物作り フレームワークに沿ったテスト 外部仕様 設計 開発 総合テスト 運用テスト 共通化可能部分のピックアップ 共通化部分の処理方式決定 MVC フレームワーク提供コンポーネント適用部分の決定 全体のクラス設計 設計におけるポイント 反省 業務寄りのコンポーネントの見出しが不十分 業務分析からのモデリングが必要

15 2-4 コンポーネント化対象エリアの検討 システムフレーム ( 業務組立て ) ポータル ビジネスプロセス間接続 業務パッケージフレーム ( 機能組立て ) シナリオコントロール システム 業務要素 経営経理システム顧客支援システムサプライチェーン支援システム営業支援システム 表示 引当 入庫 資材調達販売管理経費処理 原価管理在庫管理案件管理物流 共通コンポーネント 検索 チェック 変換 保管 承認 編集 認証 出庫 受注 与信 機能要素 市場情報顧客管理工程管理検索編集表示認証引当与信 変換チェック承認保管入庫出庫受注 共通ライブラリ 属性情報 制御情報 業務マスタ ビジネスプロセス 共通情報 ルール処理情報制御情報

16 2-5 コンポーネントの粒度 販売管理 受注 業務機能 Component システム機能 Component 与信 在庫引当出荷指示出荷売上計上検収請求回収 引当出庫棚卸在庫管理 購買管理 生産管理 認証 情報取得 登録 入庫

17 2-6 モデリングとは モデリングとは モデルとは モデルを作ること 情報システムなどの開発において複雑な構造を抽象化し 単純化したもの 例 フローチャートのように視覚的に表現された図形の集まり モデル ソースコードモデリングの対象となる実態そのもの システム要件の分析 何 を作るべきか考えること システムの設計 どう 作るべきかを考えること

18 2-7 MDA と UML MDA(Model-Driven Architecture): モデル駆動型アーキテクチャ モデリング主導のシステム開発を実現する参照アーキテクチャ OMG* ( 国際標準化団体 ) が普及活動中 UML(Unified Modeling Language): 統一モデリング言語 分析 / モデリングの際に利用する 言語 1997 年に OMG が標準化 *OMG(Object Management Group): オブジェクト指向技術の標準化 普及をすすめるため 1989 年に設立された標準化団体

19 2-8 MDA による開発アプローチ 業務モデルと IT モデルを分離し それぞれ独立したモデルで定義し プラットフォーム決定時 業務モデルを設計モデルにマッピングする体系 CIM(Computation-Independent Model) PIM(Platform-Independent Model) 実装技術やプラットフォームに依存しないモデル ( ビジネスロジック ) CIM PIM ビジネスプロセスビジネスエンティティビジネスイベントビジネスルール PSM 分析モデルマッピングルール設計モデル アーキテクチャ PIM の情報を特定のミドルウェア上にどのようにマッピングするかを定義したもの PSM(Platform-Specific Model) 特定の実装技術やプラットフォームに依存したモデル MDA(Model-Driven Architecture).NET J2EE 実装技術 プログラムソース

20 2-9 UML の種類 (UML2.0 の例 ) UML 種別アクティビティ図ユースケース図クラス図オブジェクト図ステートマシン図シーケンス図パッケージ図複合構造図コミュニケーション図インタラクション オーバービュー図タイミング図コンポーネント図配置図 概要 業務フローなどアクションの実行の流れを表現できる アクター ( システム外のユーザや他のシステムなど ) との間での外部アクションとその関係を表現できる クラス ( 型 ) が持つ属性と その操作の関係を表現できる クラス図を導き出すための補助的なものであり クラス図と異なるのはインスタンス ( クラスからの生成物 ) を表現する 特にクラスの中で状態がある場合 その状態遷移を表現する 複数のオブジェクト間のメッセージの流れを時間軸中心で表現できる クラスなどをグルーピングして表現できる 全体 - 部分構造をもつクラスの実行時の構造を示す インスタンス間の相互作用を構造中心に表現する 条件によって異なる動作をするシーケンス図を アクティビティー図の中に含めることで表現する インスタンス間の状態遷移や相互作用を時間制約付きで表現する 実装コンポーネントとその関係を表現できる ハードウェアとその間の関係を表現できる

21 ンポーネントベース一般的な手法2-10 コンポーネントベースモデリングの特徴 膨大なユースケース 膨大なクラスと複雑な関連 コンポーネントの 切り出しが困難 になる モデリングの段階から複数のシンプルなクラス図コシステム化範囲を分割

22 業務分析業務要件システム要件システム分析要求分析 アークテクチャ システム設計実装 非機能要件プラットフォーム依存2-11 コンポーネントベースモデリングの全体像プラットフォーム非依存外部インタフェースビジネスインタフェース 顧客受注係 内部での構造と振る舞いビジネスモデル 与信見積 ビジネスフェーズ 注文する 受注を処理する 受注 受注受付在庫引当製造手配 ビジネス要件 出荷指示 ユースケース ( 要求機能 ) 受注係与信依頼を行う与信管理システム 分析オブジェクトモデル 顧客グループ顧客 1 1..* 顧客グループコード 顧客コード 顧客グループ名 顧客名 1 1..* 顧客所在地 事業所名 事業所郵便番号 事業所住所 事業所 TEL 調査係 Presentaion 画面 1: 顧客を検索する ( 検索条件 ) 情報システム化フェーズ Domain 処理 2: 顧客情報 := 顧客情報を取得する () DataSource 顧客 アーキテクチャ適用 3: 顧客情報 := 顧客情報を取得する () ユーザインタフェース 設計オブジェクトモデル アーキテクチャ依存フェーズ プラットフォーム適用 ユーザ操作 プラットフォーム実装モデル プラットフォーム依存フェーズ

23 コンポーネントベースモデリング開発プロセス要件定義 1開発対象業務の整理2アクティビティ図3システム化範囲の決定4ユースケース図5ユースケースシナリオ6コンポーネント外部仕様図7分析クラス図8論理データモデル9分析シーケンス図10ステートマシン図11コンポーネント仕様図12論理クラス図13論理シーケンス図14リクエストマッピング15DBマッピング業務分析 (CIM) 要求分析 (PIM) システム分析 (PIM) 論理設計 (PSM) 実装 テスト非機能要件定義用語辞書の作成 メンテナンスアーキテクチャ設計画面 / 帳票設計 DB 設計 16実装クラス図19テスト仕様17実装シーケンス図20単体テスト18実装連動テスト21 イテレーション情報システム部門 ( 上流設計者 ) 上流設計者 実装者実装者業務主管部門等参画部署基本設計詳細設計実装 2-12

24 業務IM開発プロセス関連図C要求分析PIMステム分析モデル シシステム設計PSM実装テスト分析1 開発対象業務の整理 2 ビジネスプロセス分析 アクティビティ図 凡例 ( ): オプションのドキュメント : 上位ドキュメントの洗練化版または派生物 3 システム化範囲の決定 アクティビティ図 4 要求機能分析 ユースケース図 5 要求機能詳細分析 ユースケースシナリオ 画面モックアップ 6 コンポーネント外部仕様分析 コンポーネント外部仕様図 7コンポーネント内部情報分析 分析クラス図 9コンポーネント内部振舞分析 分析シーケンス図 11 コンポーネント仕様分析 コンポーネント仕様図 10オブジェクト状態遷移分析 ( ステートマシン図 ) ビジネスコンポーネントモデル 8 システム全体情報分析 論理データ 実装アーキテクチャの決定 12 論理クラス図 13 論理シーケンス図 14 リクエストマッピング 画面仕様書など 15DB マッピング ER 図など 16 実装クラス図 17 実装シーケンス図 18 実装 19テスト仕様書 20 単体テスト 21 連動テスト

25 Contents 1. SOA とコンポーネントの事例 2. コンポーネントベースモデリングの背景 3. コンポーネントベースモデリングの事例 4. プロジェクト推進のポイント

26 3-1 開発対象業務の整理とアクティビティ図 ロール ( アクティビティ図 ) アクター ( ユースケース図 ) 顧客受注係調査係在庫管理係 受注 与信 注文を依頼する 信用調査を依頼する 与信 NG 与信を行う 受注受付 与信 OK 在庫引当 受注登録を行う 在庫を確認する 製造手配 在庫なし 出荷指示 製造手配を行う 在庫あり 出荷を指示する

27 3-2 開発対象業務の整理とアクティビティ図 ( 階層 ) 受注係 調査係 受注 与信 信用調査を依頼する 新規顧客 既存顧客 信用調査顧客情報登録与信限度額登録与信限度チェック与信結果連絡 OK NG 注文をキャンセルする 信用調査を行う NG OK 顧客情報と与信限度額を登録する与信限度額をチェックする与信結果を連絡する

28 3-3 システム化対象範囲の決定 受注係 調査係 受注 与信 信用調査を依頼する 新規顧客 既存顧客 信用調査顧客情報登録与信限度額登録与信限度チェック与信結果連絡システム化対象範囲 OK NG 注文をキャンセルする 信用調査を行う NG OK 顧客情報と与信限度額を登録する与信限度額をチェックする与信結果を連絡する

29 3-4 ユースケース図 与信管理コンポーネント 受注 与信信用調査顧客情報登録与信限度額登録与信限度チェック与信結果連絡 顧客を検索する顧客を登録 更新する与信限度額を登録 更新する与信限度額をチェックする 調査係 アクター ( アクティビティ図でのロール )

30 3-5 ユースケース図 ( コンポーネント導出 ) 与信管理コンポーネント 顧客管理コンポーネント 顧客を検索する 顧客を検索する 顧客を登録 更新する 顧客を登録 更新する 与信管理コンポーネント 調査係 与信限度額を登録 更新する 与信限度額を登録 更新する 調査係 与信限度額をチェックする 与信限度額をチェックする ユースケースでの共通事項を見出し 必要があればコンポーネント分割を行う

31 3-6 ユースケースシナリオ ユースケース図 顧客管理コンポーネント 顧客を検索する 調査係 顧客を登録 更新する シナリオはユースケース単位シナリオ記述テンプレートなどを用意

32 3-7 分析クラス図 ユースケースシナリオ 画面モックアップ 顧客情報 顧客 Gr 登録 削除 顧客名 分析クラス図 住所 TEL 検索 検索 顧客グループ 顧客グループコード 顧客グループ名 1 1..* 顧客 顧客コード 顧客名 1 1 与信 与信限度額 1 1..* 顧客所在地 事業所名 事業所郵便番号 事業所住所 事業所 TEL 論理データモデル DB 設計へ

33 3-8 分析シーケンス図 : ステレオタイプ : オブジェクト 調査係 Presentation 画面 Domain 処理 DataSource 顧客 1 : 顧客を検索する ( 検索条件 ) 2 : 顧客情報 : = 顧客情報を取得する ( ) ユースケース単位 ( アクション ) 3 : 顧客情報 : = 顧客情報を取得する ( ) 機能 情報

34 3-9 コンポーネント仕様図 ( パッケージ図 ) 分析クラス図 ( 内部仕様 ) 顧客グループ 顧客グループコード 顧客グループ名 1 1..* 顧客 顧客コード 顧客名 1 1..* 顧客所在地 事業所名 事業所郵便番号 事業所住所 事業所 TEL ユースケース図 ( 外部仕様 ) 顧客管理コンポーネント コンポーネント仕様 顧客管理コンポーネント 顧客グループ 顧客グループコード 顧客グループ名 1 1..* 1 1..* 顧客 顧客コード 顧客名 顧客所在地 事業所名 事業所郵便番号 事業所住所 事業所 TEL 調査係 顧客を検索する 顧客を登録 更新する 顧客を検索する ( ): 顧客情報顧客を登録 更新する ( 顧客情報 )

35 3-10 コンポーネント構成仕様書 業務機能コンポーネントレベルのシナリオ システム機能コンポーネントレベルのシナリオ Excel の計算機能による自動計算

36 Contents 1. SOA とコンポーネントの事例 2. コンポーネントベースモデリングの背景 3. コンポーネントベースモデリングの事例 4. プロジェクト推進のポイント

37 4-1 システム開発における共通処理機能の重複 見積コンポーネント ( 業務機能 ) 受注受付コンポーネント ( 業務機能 ) 見積採番する 受注採番する 見積書を入力する 見積登録する 受注を入力する 見積を取得する エラー MSG を出力する 受注登録する 受注係 請期回答する エラー MSGを出力する顧客要求納期を入力する ログを出力する ログを出力する カレンダーを取得する カレンダーを取得する 業務機能コンポーネント基本設計時 システム機能コンポーネント ( 共通 ) が決まっていないと 重複して作りこんでしまう危険性が大きい

38 4-2 共通コンポーネントによる重複開発の回避 見積係 見積書を入力する 顧客要求納期を入力する 受注受付コンポーネント ( 業務機能 ) 受注を入力する ( 業務機能 ) 共通コンポーネント ( システム機能 ) 採番管理見積マスタデータアクセス受注マスタデータアクセス MSG 出力管理ログ出力管理 受注受付コンポーネント 受注係請期回答するカレンダー管理 業務機能コンポーネントの基本設計前にシステム機能コンポーネント ( 共通 ) を設計しておき それを元に設計する

39 4-3 各種標準化 共通化の決定と工程での位置付け 標準開発プロセスの策定 標準開発プロセス策定 各種基準書の策定 各種ドキュメントの策定 使うことを前提として設計 共通コンポーネント プロジェクト全体で利用可能な共通コンポーネント 業務分析要件定義基本設計詳細設計実装テスト 標準アーキテクチャ方針の決定 適用ハードウェア,OS, ミドルウェアなどの製品決定 適用する開発言語 各種支援ツールの決定 適用するフレームワーク決定 情報構造 アクセス方針決定 etc 標準処理方式設計 フレームワーク 障害処理方式適用方式 システム間通信方式 セキュリティ方式 認証方式 データアクセス方式 ログ出力方式 帳票出力方式 etc

40 4-4 プロジェクト推進体制の事例 EA:Enterprize Architecture BA:Business Architecture DA:Data Architecture AA:Application Architecture 情報システムでの業務改善計画 データ基盤計画 AP 開発基盤計画 基本方針 TA:Technology Architecture インフラ基盤計画 チーム体制 標準化チーム 共通コンポーネントチーム 共通マスタチーム 運用管理チーム AP 開発チーム ( 複数 ) 役割 標準開発プロセスや各種基準 ドキュメントの標準化 各種アーキテクチャ標準や共通処理方式方針などを決定する 特にシステム機能コンポーネントの提供と保守 管理 AP チームへのデザインレビューへの参画 共通マスタの設計とデータアクセスコンポーネントの提供 インフラ環境の構築と各種 AP の運用管理方式決定 各種 AP の開発

41 4-5 まとめ コンポーネント化においては 業務分析からのモデリングが必要 そのための一貫した分析 開発プロセスと 開発支援などの統一が必要 MDA ベースではモデルそのものの再利用化も可能となる 作成したコンポーネントを効率よく管理 運用するための体制と仕掛けが必須