アプリケーション開発におけるコンポーネントベースモデリングの適用
7
0
0
全文
(2) 合、それに応じて業務の分析から情報シス テム化というサイクルを繰り返す必要があ る。 MDA で は 、業 務 の 変 化 と プ ラ ッ ト フ ォ ー ムの変化のスピードが異なる点に注目し、 業務分析の視点と設計・実装の視点を分離 してそれぞれ独立したモデルを作成するこ とで、プラットフォームやアーキテクチャ が変わっても業務分析モデルを流用できる ことを目指している。業務分析モデルを見 出すためのモデリング工程、あるいはそれ らを情報システム化するための設計工程を 分 け 、 そ れ ぞ れ の 工 程 で OMG が 制 定 し た UML を 共 通 言 語 と し て 使 用 す る 。分 析・設 計工程は次の３つのフェーズに分けられる。 (1) CIM（ 業 務 分 析 ） システムの構造は提示せず、業務の構 造やフローを明確にするフェーズである。 (2) PIM（ 要 求 分 析 、 シ ス テ ム 分 析 ） プラットフォームに依存しないモデル を作成するフェーズである。要求分析で はシステムの外部仕様を、システム分析 では内部仕様を定義する。 (3) PSM PIM を 特 定 の 技 術 に マ ッ ピ ン グ し 、プ ラットフォームやアーキテクチャに依存 したモデルを導出するフェーズである。. ２．コンポーネントベースモデリングの目 的と定義 2.1 目 的 開発プロセスと方法論の策定にあたり、 以下に示す事項を目的とした。 (1) 分 析 工 程 で の コ ン ポ ー ネ ン ト の 導 出 が可能なこと 業務をモデリングし、そのモデル自体 を流用できることはもちろんのこと、実 装時の工数短縮のため、業務分析工程で のコンポーネントの見出しを可能とする。 モデルはコンポーネントの組立型で実装 できることを目指す。 (2) 各 開 発 プ ロ セ ス の 関 連 が 明 確 な こ と 上位プロセスの成果物が次のプロセス の入力となる部分を明確にし、プロセス 間の関係を導き出すことで、ある程度機 械的な判断による次工程のドキュメント 作成を可能とする。. 図 1 に EA と MDA の 概 要 を 示 す 。. 2.2 コ ン ポ ー ネ ン ト の 定 義 ある業務を考えた場合、それは小さな 単位の業務の組立で表現でき、さらにそ の業務はより小さな業務機能の組み合わ せで表現できる。その階層は業務機能階 層となり、実装の際にコンポーネントに マッピングできると考えた。図２にコン ポーネントの定義とこれを導出するため に分析工程で使用するダイヤグラムを示 す。. ビジネス・アーキテクチャ ビジネス・アーキテクチャ. ビジネス ビジネス コンポーネント コンポーネント. データ・アーキテクチャ アプリケーション・アーキテクチャ アプリケーション・アーキテクチャ. 受注. テクノロジ・アーキテクチャ テクノロジ・アーキテクチャ. 出荷. UML (Unified Modeling Language)による表記 Language)による表記. CIM・PIM. マッピング ルール. 分析モデル. アーキテクチャ. 在庫引当( C_ I M). 検収. PSM 設計モデル. 在庫引当依頼. 在庫確認( C_ I M_ 001) 製造手配. 見積内容選択（ B_ I M_ 001_ 04） 在庫引当( C_ I M_ 002). 請求 出荷指示. PIMの情報を特定 のミドルウェア上 にどのようにマッ ピングするかを定 義したもの. 受注内容入力（ B_ I M_ 001_ 05） 引当結果連絡. 回収 受注内容登録（ B_ I M_ 001_ 06）. J2EE .NET. 業務単位で 作成するダイアグラム. ビジネスコンポーネント単位で 作成するダイアグラム. 業務機能コンポーネント単位で 作成するダイアグラム. ・ユースケースシナリオ ･アクティビティ図・システム全体図 ・ユースケースシナリオ ･アクティビティ図 ･アクティビティ図 ･アクティビティ図・システム全体図 ・分析シーケンス図 ・分析シーケンス図 ･ユースケース図 ・分析データモデル ・分析データモデル ･ユースケース図 ・ビジネスコンポーネント外部仕様図 ・ビジネスコンポーネント外部仕様図 ・ビジネスコンポーネント仕様図 ・ビジネスコンポーネント仕様図. 実装技術. MDA(ModelMDA(Model-Driven Architecture ). 図1. 顧客検索（ B_ I M_ 001_ 01）. 見積内容検索（ B_ I M_ 001_ 03）. 売上計上. プログラム ソース. 受注内容登録( B_ I M_ 001). システム機能 システム機能 コンポーネント コンポーネント. 顧客選択（ B_ I M_ 001_ 02）. 販売管理. ・・・. ●ビジネスプロセス ●ビジネスエンティティ ●ビジネスイベント ●ビジネスルール. 受注受付( B_ I M). 業務機能 業務機能 コンポーネント コンポーネント. EA と MDA の 概 要. 図２ 本 報 告 で は CIM、PIM に お け る モ デ リ ン グの開発プロセスと方法論策定について述 べる。. コンポーネントの定義. 図２は販売管理の例であるが、販売管 理は受注や出荷などの業務で構成される。 さらに受注は、受注受付、在庫引当、出. 2 −24−.
(3) は数種類の図が規定されているが、全 てを利用する必要はないため、何を見 出すのかの目的を明確にした上で必要 なものだけを採用した。また、モデリ ン グ の 目 的 に よ っ て は UML で 規 定 さ れた図だけでは仕様を記述するには足 りない場合がある。本報告においても 同 様 、UML だ け で は 不 足 す る 図 や 資 料 は 別 途 作 成 し 、CIM・PIM 作 成 の た め の工程と作成モデル、またその関連を 図４のように開発プロセスとして定義 した。 業務主管部門等 参画部署 情報システム部門（上流設計者） . 実装 クラス図. テスト仕様. 実装 シーケンス図. 単体 テスト. ⑮ＤＢマッピング. 実装. 連動 テスト. または派生物. ⑤要求機能分析 ⑤要求機能分析. ③システム化 ③システム化 範囲の決定 範囲の決定. 【ユースケース図】 【ユースケース図】. ④開発対象 ④開発対象 全体整理 全体整理. 【※アクティビティ図】 【※アクティビティ図】. ⑥要求機能詳細分析 ⑥要求機能詳細分析 【ユースケースシナリオ】 【ユースケースシナリオ】. 【システム関連図】 【システム関連図】. ⑦ビジネスコンポー ⑦ビジネスコンポー ネント外部仕様分析 ネント外部仕様分析 【コンポーネント 【コンポーネント 外部仕様図】 外部仕様図】. 23 【画面スケッチ】 23 【画面スケッチ】. P I M. プラットフォーム依存フェーズ プラットフォーム依存フェーズ. シ ステ ム分 析. プラットフォーム実装モデル. ⑬論理 シーケンス図. アーキテクチャ依存フェーズ アーキテクチャ依存フェーズ. 【アクティビティ図】 【アクティビティ図】. プラットフォーム適用. ユーザ操作. ⑫論理 クラス図. ⑩ステートチャート図. ⑨分析 シーケンス図. 凡例 ( )：オプションのドキュメント. 凡例 ( )：オプションのドキュメント ②ビジネスプロセス分析 ②ビジネスプロセス分析 ①開発対象業務の整理 ①開発対象業務の整理 ※：上位ドキュメントの洗練化版 コンポーネントベース開発アプローチ2 ※：上位ドキュメントの洗練化版 または派生物. 要求分析. シス ステ テム ム設 設計 計 シ. (PSM). ⑦分析 クラス図. C I M. 業務分析. 要求 求分 分析 析・ ・ 要 シス ステ テム ム分 分析 析 シ. プラットフォーム依存. アークテクチャ・ 非機能要件. ＥＡデ(ータ・ アーキテクチャ ). システム要件. 情報システム化フェーズ 情報システム化フェーズ. (PIM) 設計オブジェクトモデル. ⑧論理 データモデル. 図４ 開発プロセス これらのプロセスはお互いに関連を 持っており、この関係も明確にした。 図５にそれぞれの工程のプロセス関連 図を示す。. アーキテクチャ適用. ユーザインターフェース. ⑥コンポーネント外部 仕様. 非機能要件定義. ビジネス要件. 分析オブジェクトモデル. ⑤ユースケースシナリオ. アーキテクチャ設計 用語辞書の作成、メンテナンス. (CIM) ユースケース(要求機能). 実装者 実装・テスト. 論理設計(PSM). ＤＢ設計. ビジネスフェーズ ビジネスフェーズ. 受注を 処理する. 上流設計者，実装者. 画面／帳票設計. 受注係. 注文する. システム分析(PIM). 繰り返し. 内部での構造と振る舞い ビジネスモデル. ④ユースケース図. 顧客. ②アクティビティ図. 業務 務分 分析 析 業. 業務要件. プラットフォーム非依存. ＥＡビ(ジネス・ ＥＡ ア(プリケーション・ ＥＡテ(クノロジ・ アーキテクチャ ) アーキテクチャ ) アーキテクチャ ). 外部インターフェース ビジネスインターフェース. ③システム化 範囲 の決定. ①開発対 象業務 の整理. ３．開発プロセスの策定 3.1 開 発 プ ロ セ ス の 概 略 開発プロセスを検討するに当たり、 MDA の CIM、 PIM 工 程 と EA と の 関 連、さらに分析フェーズごとの外部イ ンタフェースおよび必要となる内部の 振舞いを開発プロセス概略として図３ に示す。. 要求分析(PIM). ⑪ビジネス コンポーネント仕 様. 業務分析(CIM). ⑭リクエストマッピング. 荷指示などの業務で構成される。かつ、 受注受付は顧客検索、見積検索などの機 能で組み立てられている。ここで図２に 示すように、それぞれのレイヤをビジネ スコンポーネント、業務機能コンポーネ ント、システム機能コンポーネントと定 義した。 このような構成を見出してモデリング すれば、ビジネスコンポーネントは業務 機能コンポーネントの組立であり、その 業務機能コンポーネントはシステム機能 コンポーネントの組立となる。また、下 位のコンポーネントは上位コンポーネン トでの共有が可能となり、実装時にのみ 共有コンポーネントを見出す場合に比べ、 開発工数が短縮できる。. ⑧ビジネスコンポー ⑧ビジネスコンポー ネント内部情報分析 ネント内部情報分析. ⑨ビジネスコンポー ⑨ビジネスコンポー ネント内部振舞分析 ネント内部振舞分析. 【分析クラス図】 【分析クラス図】. 【分析シーケンス図】 【分析シーケンス図】. ⑪ビジネスコンポー ⑪ビジネスコンポー ネント仕様分析 ネント仕様分析 【※ビジネスコンポーネント仕様図】 【※ビジネスコンポーネント仕様図】. ⑩オブジェクト状態遷移分析 ⑩オブジェクト状態遷移分析. ⑫システム全体 ⑫システム全体 情報分析 情報分析. 【【 (ステートチャート図) (ステートチャート図)】】. 実装・ 実装・ テスト テ テスト スト . 【※論理データモデル】 【※論理データモデル】. システ ム設 計. 図３. P S M. 開発プロセス概略. 実装. 【※⑬設計クラス図】 【※⑬設計クラス図】. 【※⑭設計シーケンス図】 【※⑭設計シーケンス図】. ⑮リクエストマッピング ⑮リクエストマッピング. ⑯DBマッピング ⑯DBマッピング 【ＥＲ図など】 【ＥＲ図など】. 【画面仕様書など】 【画面仕様書など】. 【※⑰実装クラス図】 【※⑰実装クラス図】. テ スト. 3.2 開 発 プ ロ セ ス の 詳 細 次にそれぞれの詳細な工程を見出し、 開発プロセスを策定した。開発プロセ ス の 策 定 に お い て は 、MDA 工 程 に そ れ ぞ れ UML で の 作 成 物 を 当 て は め 、 か つ、コンポーネント見出しが可能とな る よ う な プ ロ セ ス を 検 討 し た 。 UML. 実装アーキテクチャの決定 実装アーキテクチャの決定. 【※⑱実装シーケンス図】 【※⑱実装シーケンス図】. 【⑳テスト仕様書】 【⑳テスト仕様書】. 図５. ⑲実 装 ⑲実 装 . 21 単体テスト 単体テスト. 22 連動テスト 連動テスト . 開発プロセス関連図. ４ .開 発 方 法 論 の 策 定 次に策定した開発プロセスの個々の工程. 3 −25−.
(4) で、コンポーネントを導出していくための 方法について考えた。 4.1 業 務 分 析 工 程 (CIM) 業務分析では、対象業務にどのような ビジネスプロセスが存在するかを明確に する。業務に関連する部署や人などを洗 い出し、業務フローを明確にすることで 業務を細分化し、業務の機能構造を明確 にする。 (1) 開 発 対 象 業 務 の 整 理 【業務機能階層図】 既に準備されている資料の利用や、 業務主管部門へのヒアリングにより業 務を細分化し、業務機能階層図として 整理する。なお、この工程は次のビジ ネスプロセス分析の結果として導出す るケースもある。 (2)ビ ジ ネ ス プ ロ セ ス の 分 析 【アクティビティ図】 対象業務に関連する部署や人などを 洗い出し、業務の流れをアクティビテ ィ図として表す。また、アクティビテ ィ図で業務を分割し、分割した業務の 構 造 を (1)の「 開 発 対 象 業 務 の 整 理 」の 業務機能階層図へ反映する。これによ り、業務機能コンポーネント、システ ム機能コンポーネントの対象を導出す る。図６に業務機能階層図への反映を 示す。 顧客. 受注係. 信用調査係. ム化範囲を決定し、同時におおまかな入 出力情報を洗い出す。その結果から、シ ステム全体を俯瞰できる全体図を作成す る。また、システム化範囲の機能を明確 にするために、ユーザーや外部システム との関係を定義した後、システム化範囲 の詳細な処理を記述する。これらの情報 をもとに、ビジネスコンポーネントの仕 様決定に先立ち、そのビジネスコンポー ネントが外部に公開するインターフェー スを明確にする。 (1) シ ス テ ム 化 範 囲 の 決 定 業務分析の結果であるアクティビティ 図を用いて、システム化する範囲を決定 する。アクティビティ図は業務フロー図 であるため、システム化対象外のアクテ ィビティも導出されている。このため、 それらの中から今回のシステム化の対象 を絞り込む。 (2) 開 発 対 象 全 体 の 整 理 【システム全体図】 開発対象に存在するビジネスコンポー ネントと、それがユーザーに提供する機 能、そこでやりとりされる情報の相関関 係をシステム全体図として表す。図７に システム全体図を示す。 アクティビティ図. 業務機能階層図. ロール アクティビティ アクティビティ. ビジネス ビジネス コンポーネ コンポーネント ント. 入出力情報 入出力情報. 在庫管理係. 業務機能階層図①. 顧客情報 注文を 依頼する. 受注. 信用調査を 依頼する. 与信を 行う. 受注受付 B-I M. 在庫引当 C-I M. 与信管理シ ス テ ム E_ I M. 注文受付 A-I M. [ 与信NG]. [ 与信OK]. 出荷. アクティビティ図（受注）. 見積を 行う [NG ]. 注文情報. 在庫情報. 在庫情報. 顧客情報. [OK]. 検収 販売管理 業務機能階層図②. 正式注文を 行う. 注文受付. 受注受付を 行う. 登録する. 確認する. 引当て る. 依頼する. 在庫を 確認する. 与信. 売上計上. [ 在庫なし ]. 見積. 請求. 受注. [ 在庫あり ]. 在庫管理係. 製造手配を 行う. 受注受付 出荷を 指示する. 回収. 販売管理. 出荷. 受注係. 在庫引当. 検収 製造手配. 売上計上 出荷指示. 請求. 図７. システム全体図. 回収. 図６. 業務機能階層図への反映. 4.2 要 求 分 析 工 程 (PIM) 業務分析の結果から対象業務のシステ. 4 −26−. (3) 要 求 機 能 の 分 析 【 ユ ー ス ケ ー ス 図 】 業務機能コンポーネントの対象とな るものをユースケース、外部要因（ユ ーザーや外部システム）をアクターと.
(5) ユースケースシナリオ. アクティビティ図. し、それらの関係をユースケース図と して表す。ユースケース図は下記の観 点で作成する。 (a) ユ ー ス ケ ー ス 図 は シ ス テ ム 化 範 囲 のアクティビティをユースケースと して定義する。 (b) シ ス テ ム 化 範 囲 の ア ク テ ィ ビ テ ィ を担当するロールをアクターとして 定義する。 (c) ビ ジ ネ ス コ ン ポ ー ネ ン ト ご と に ユ ースケース図を作成する。 (d) ビ ジ ネ ス プ ロ セ ス に 登 場 す る 外 部 システムや他コンポーネントはアク ターとして定義する。 (e) 外 部 シ ス テ ム や 他 コ ン ポ ー ネ ン ト を利用するユースケースはそのアク ターと関連付ける。 この工程は次の工程である「要求機能 の詳細分析」結果を反映することで、 要求機能のさらなる細分化を行う必要 がある。 (4)要 求 機 能 の 詳 細 分 析 【ユースケースシナリオ】 画面レイアウト、現在使用している 紙の帳票などから入出力情報を明確に し、ユースケースの詳細な処理をユー スケースシナリオとして記述する。ユ ースケースシナリオは、システム化範 囲のアクティビティと入出力情報を参 考にしてさらなる分析を行い、処理の 内容を詳細ステップとして文章で記述 す る 。 ユ ー ス ケ ー ス シ ナ リ オ を (3)の 「要求機能の分析」の結果に反映する ことで、システム機能コンポーネント の細分化と洗練化を行う。図 8 にユー スケース図への反映例を示す。. ロール ロール. システム化範囲の システム化範囲の アクティビティ アクティビティ. ステップ ステップ. ステップ ステップ. ・・・・. 受注受付コ ン ポーネン ト （ B_ I M） include. 顧客を 検索する （ ０ １ ） include. 顧客を 選択する （ ０ ２ ） include. 見積内容を 検索する （ ０ ３ ） 受注内容を 登録する （ ０ ０ １ ）. 受注係. include. 見積内容を 選択する （ ０ ４ ） include. 受注内容を 入力する （ ０ ５ ） include. 受注情報を 登録する （ ０ ６ ）. ユースケース図への反映. 図８. ユースケース図への反映. (5) ビ ジ ネ ス コ ン ポ ー ネ ン ト 外 部 仕 様 の 分析 【ビジネスコンポーネント外部仕様図】 ユースケース図とユースケースシナ リオを基に、ビジネスコンポーネント が外部に公開する機能と、そこで入出 力される情報をビジネスコンポーネン ト外部仕様図として表す。ビジネスコ ンポーネント外部仕様図はインターフ ェ ー ス と オ ペ レ ー シ ョ ン （ メ ソ ッ ド ）、 入出力される情報（引数と戻り値）を 記述する。図９に外部仕様図の例を示 す。 階層化したユースケース図. ユースケースシナリオ シナリオの入出力情報 シナリオの入出力情報. 受注受付 B-I M 受注内容を 登録する. 顧客を 検索する （ 顧客識別情報） ： 顧客リ ス ト 顧客を 選択する （ 顧客） 見積内容を 検索する （ 顧客識別情報） ： 見積リ ス ト 見積内容を 選択する （ 見積） 受注内容を 入力する （ 商品名、 数量） 受注情報を 登録する （ 受注情報）. コンポーネント外部仕様図. サブプロセス サブプロセス. 業務機能コンポーネントID 業務機能コンポーネントID. 上位のユースケース 上位のユースケース 階層化したユースケース図. 図９. ﾋﾞｼﾞﾈｽｺﾝﾎﾟｰﾈﾝﾄ外 部 仕 様 図. 4.3 シ ス テ ム 分 析 工 程 (PIM) システム分析では、ビジネスコンポー ネントで使用する情報とその関連を明確 にする。また、そのビジネスコンポーネ ントのインターフェース、システム化範 囲の機能、入出力情報の関係から、シス. 5 −27−.
(6) 成 す る 。図 11 に ビ ジ ネ ス コ ン ポ ー ネ ン ト仕様図を示す。. テムの内部処理手順を明確にする。これ らの結果より、ビジネスコンポーネント の外部仕様と内部仕様を明確にする。さ らにＤＢ設計の状態フラグ定義などに利 用するために、オブジェクトの状態遷移 を明確にする。最後の工程として、シス テム全体のデータ構造を明確にする。. コンポーネント外部仕様図 インターフェース インターフェース オペレーション オペレーション. *. 受注 受注番号 受注日付. 1. *. *. 1 顧客. * 1. 1. 顧客番号 顧客名 住所 電話番号 E-mail. 受注明細 受注数量 受注単価. 商品 商品コ ード 商品名 単価. 社員 社員番号 社員名 1. 1. 1 * *. 見積 見積番号 回答日. * 1. *. 見積明細 見積数量 見積単価. 分析クラス図. 図 10. 分析クラス図. (2) ビ ジ ネ ス コ ン ポ ー ネ ン ト 内 部 の 振 舞 い分析【分析シーケンス図】 シーケンス図とは、ある処理を実現 するために行われるオブジェクト間の 相互作用（メッセージのやりとり）を 時系列にそって表現したものである。 ここでは、シナリオのステップを参考 にし、ビジネスコンポーネントが起動 された際の内部処理手順をシーケンス 図で表現する。シーケンス図はビジネ スコンポーネントのインターフェース 単位に作成する。 (3) ビ ジ ネ ス コ ン ポ ー ネ ン ト 仕 様 の 分 析 【※ビジネスコンポーネント仕様図】 ビジネスコンポーネント外部仕様図 と分析シーケンス図と分析クラス図か らビジネスコンポーネント仕様図を作. メッセージ メッセージ. 受注受付コ ン ポーネン ト B-I M. Presentation 受注登録UI + + + + + +. 受注内容を 登録する. 顧客を 検索する ( 顧客識別情報) 顧客リ スト を 表示する ( 顧客リ ス ト ) 顧客を 選択する ( 顧客) 見積内容を 検索する ( 顧客識別情報) 見積リ スト を 表示する ( 見積リ ス ト ) 見積内容を 選択する ( 見積) 受注内容を 入力する ( 受注数量, 受注単価) 受注情報を 登録する ( 受注情報). 顧客を 検索する （ 顧客識別情報） ： 顧客リ スト 顧客を 選択する （ 顧客） 見積内容を 検索する （ 顧客識別情報） ： 見積リ ス ト 見積内容を 選択する （ 見積） 受注内容を 入力する （ 商品名、 数量） 受注情報を 登録する （ 受注情報）. *. Da taSource 受注 - 受注番号 - 受注日付. DataSource 受注明細. 1. *. *. 1. Domain 受注登録管理 + 顧客を 検索する ( 顧客識別情報) : 顧客リ スト + 見積内容を 検索する ( 顧客識別情報) : 見積リ スト + 受注情報を 登録する ( 受注情報). - 受注数量 - 受注単価 + 受注明細を 登録する ( 受注明細情報). + 受注情報を 登録する ( 受注情報). Da taSource 顧客. * 1. 1. DataSource 商品. Da taSource 社員. - 顧客番号 - 顧客名 - 住所 - 電話番号 - E-mail. - 商品コ ード - 商品名 - 単価. - 社員番号 - 社員名 1. + 顧客を 検索する ( 顧客識別情報) : 顧客リ スト 1. 1. *. *. Da taSource 見積 - 見積番号 - 回答日. * 1. DataSource 見積明細. * - 見積数量 - 見積単価. + 見積内容を 検索する ( 顧客識別情報) : 見積リ ス ト. ビジネスコンポーネント仕様図. 図 11. オブジェクト オブジェクト. 分析シーケンス図. ビジネス ビジネス コンポーネントID コンポーネントID. (1) ビ ジ ネ ス コ ン ポ ー ネ ン ト 内 部 の 情 報 分析【分析クラス図】 シナリオや帳票、コンポーネント外 部仕様（インターフェース）を基にそ の業務で使用する情報の静的な構造を、 分析クラス図として表す。分析クラス 図の作成が困難な場合はオブジェクト 図を作成してから分析クラス図を導き 出 す 。 図 10 に 分 析 ク ラ ス 図 を 示 す 。 オブジェクト図. 分析クラス図. ビジネスコンポーネント仕様図. (4) オ ブ ジ ェ ク ト の 状 態 遷 移 分 析 【ステートチャート図】 特に状態遷移がビジネスプロセスに影 響を与えるクラスについては、分析クラ ス図と分析シーケンス図をもとに、ステ ートチャート図を作成する。ステートチ ャート図とは、あるオブジェクトが生成 され、消滅するまでの状態遷移を表現し たものである。ユースケースシナリオ中 にステート（状態）が切り替わるイベン ト（タイミング）を明記している場合、 それを参考にして作成する。 (5)シ ス テ ム 全 体 の 情 報 分 析 【分析データモデル】 ビジネスコンポーネント単位で分析し た情報をシステム単位にまとめる。この 内 容 は 以 降 の ER 図 作 成 な ど 、DB 設 計 へ と繋げていく工程である。分析データモ デルは分析クラス図の集合体であり、ク ラスの状態を表す属性（ステートチャー ト図から導く）なども含めて作成する。 以上のように開発プロセスおよびプロセ ス間の関連、プロセス内でのコンポーネン トベースモデリングの開発方法論を策定し た。過去に経験したプロジェクトではオブ. 6−28−.
(7) ジ ェ ク ト 指 向 開 発 や UML モ デ リ ン グ と 言 ってもクラス図中心で分析した結果を実装 し、大規模なシステムでは特に実装者間の 意思の疎通が難しいために、コンポーネン トの流用がなかなかうまくいかなかった経 験を持つ。また、出来上がったコンポーネ ントはカレンダーや認証など、比較的シス テム機能に近いユーティリティコンポーネ ントが中心で、業務寄りのコンポーネント の導出・流用がうまく行かなかった。その 要因として業務分析などの上位フェーズか らの落とし込みをしなかったことが反省点 であった。 今回の方法論のように業務分析の上流で コンポーネントの導出を行えば、それを設 計、実装へと繋げていくことは比較的楽に でき開発工数も短縮できる。さらに、その モデル自身も業務が変わらない限り、流用 が可能であり、企業のビジネスモデルとし て活用できるはずである。. 参考文献 (1) David S.Frankel、”MDA モ デ ル 駆 動 型 ア ー キ テ ク チ ャ ”、日 本 ア イ・ビ ー・エ ム 株 式 会 社 TEC-JMDA 分 科 会 、 (株 )エ ス ア イ ビ ー ・ ア ク セ ス 、 2003． (2)近 藤 博 次 、 ”よ く わ か る オ ブ ジ ェ ク ト 指 向 の 基 本 と 仕 組 み ”、 （ 株 ）秀 和 シ ス テ ム 、2003． (3)長 瀬 嘉 秀 、橋 本 大 輔 、”UML シ ス テ ム 設 計 実 践 技 大 全 ”、 (株 )ナ ツ メ 社 、 2004． (4)湯 浦 克 彦 、大 坪 稔 房 、団 野 博 文 、石 井 義 明 、 古 澤 憲 一 、 桐 越 信 一 、 鈴 木 文 音 、 ”EJB コ ン ポ ー ネ ン ト に よ る Web シ ス テ ム 構 築 技 法 ”、(株 )ソ フ ト・リ サ ー チ・セ ン タ ー 、2002． (5)Martin Fowler、 ”UML モ デ リ ン グ の エ ッ セ ン ス 第 2 版 ”、 (株 )翔 永 社 、 2000． (6)渡 辺 政 彦 、飯 田 周 作 、石 田 哲 史 、山 本 修 二 、 浅 利 康 二 、 ”UML 動 的 モ デ ル に よ る 組 み 込 み 開 発 ”、 (株 )オ ー ム 社 、 2003． (7)ObjectManagementGroup、“UML 仕 様 書 ”、 (株 )ア ス キ ー 、 2001． (8)Anneke Kleppe 、 Jos Warmer 、 Wim. ５．まとめ 今回報告したコンポーネントベースでの 開発プロセスと開発方法論の策定について、 すでに数社の実際のプロジェクトでこのモ デリング手法を適用中であり、コンポーネ ントベースでの開発が行われている。実際 の分析工程では、新規開発システムの中で 導 出 し た コ ン ポ ー ネ ン ト の 70%以 上 が プ ロ ジェクト内で流用できる結果を見出してい るところもある。 現在は、この結果を実装へ持っていくま で の PSM(Platform-Specific Model) 工 程 での方法論を新たな研究内容として纏めて おり、そちらが完成すると上流から実装ま での一貫したプロセスと各工程での開発方 法論が出来上がり、より一層、コンポーネ ントベース開発の効率化を狙えると考える。 一 方 、MDA に 基 づ く CIM・PIM か ら PSM への自動切り出し、さらにプログラムソー スやＤＢ定義パラメタの自動生成など、今 後は機械化できる部分がかなりの割合を占 めることが予想される。そのためには上流 での分析方法論はより一層重要となり、今 後とも開発方法論についてのブラッシュア ップを続けていく所存である。. Bast、”MDA モ デ ル 駆 動 型 ア ー キ テ ク チ ャ 導 入 ガ イ ド ”、 (株 )イ ン プ レ ス 、 2003． (9) Doug Rosenberg、Kendall Scott、”UML オ ブ ジ ェ ク ト モ デ リ ン グ ”、(株 )ソ フ ト バ ン ク パ ブ リ ッ シ ン グ 、 2002． (10)Craig Larman、 ”実 践 UML パ タ ー ン に よ る オ ブ ジ ェ ク ト 指 向 開 発 ガ イ ド 、 (株 )プ レ ン テ ィ ス ホ ー ル 、 1998． (11)(株 )テ ク ノ ロ ジ ッ ク ア ー ト 、 ”パ タ ー ン モ デ リ ン グ ガ イ ド ”、(株 )ピ ア ソ ン ・ エ デ ュ ケ ー シ ョ ン 、 2002． (12)Ivar Jacobson 、 Grady Booch 、 James Rumbaugh、 ”UML に よ る 統 一 ソ フ ト ウ ェ ア 開 発 プ ロ セ ス ”、 (株 )翔 永 社 、 2000．. 商標および登録商標. 7-E −29−. ・ MDA, Model Driven Architecture, お よ び UML は Object Management Group, Inc.の 登 録 商 標 で す 。 ・OMG, Object Management Group, お よ び Unified Modeling Language は Object Management Group, Inc.の 商 標 で す 。.
(8)
関連したドキュメント
In this, the first ever in-depth study of the econometric practice of nonaca- demic economists, I analyse the way economists in business and government currently approach
(Construction of the strand of in- variants through enlargements (modifications ) of an idealistic filtration, and without using restriction to a hypersurface of maximal contact.) At
Keywords: continuous time random walk, Brownian motion, collision time, skew Young tableaux, tandem queue.. AMS 2000 Subject Classification: Primary:
Related to this, we examine the modular theory for positive projections from a von Neumann algebra onto a Jordan image of another von Neumann alge- bra, and use such projections
It turns out that the symbol which is defined in a probabilistic way coincides with the analytic (in the sense of pseudo-differential operators) symbol for the class of Feller
To derive a weak formulation of (1.1)–(1.8), we first assume that the functions v, p, θ and c are a classical solution of our problem. 33]) and substitute the Neumann boundary
Our method of proof can also be used to recover the rational homotopy of L K(2) S 0 as well as the chromatic splitting conjecture at primes p > 3 [16]; we only need to use the
Yin; Global existence and blow-up phenomena for an integrable two- component Camassa-Holm shallow water systems, J.. Liu; On the global existence and wave-breaking criteria for
