業界のビジネスプロセス分析および設計段階

この段階は業界のビジネスプロセスおよびビジネス情報分析および設計を遂行する段階で、大きく調査段階 とモデリング段階に分ける。これに先立ち，実際業界内部の代表的な企業などの業務処理形態に対する資料 調査とやり取りされている電子文書およびデータ項目の収集ができていなければならない。次の段階では収 集された情報などを通じてビジネスモデリング，要求事項分析，システム分析，システム設計などのサブ段

（2） 現在流通している電子文書とデータ項目の収集

‑業界内電子文書とデータ項目の収集。 

‑業界内多数の企業などで流通されている電子文書を収集して企業別プロセス定義およびこれに使用され る電子文書の比較評価テーブルを作成。 

‑業界内多数の企業などで使用している必須データ項目を収集し各々の企業別比較評価テーブルを作成。 

‑ビジネスプロセス分析および設計の成果物として導出された情報モデルとクラスダイアグラムの内容と の比較検討。 

‑上のように企業などが実際使用している電子文書とデータ項目を収集して，ビジネスプロセス分析で得ら れた結果物によって業界別に持っているデータ項目を全体的に保管するためのワークシートを利用し てデータ項目と XML タグ名を管理して部外者にも十分に理解できるようにしてコメントも受けられるよ うに公開。 

（3） 業界内で使用されているコード定義

1)業界内部で使用されている基本コードの標準化方法定義 

‑製品識別コード 

‑製品分類コード 

‑企業コード   

2)業界内部で使用されている情報のコード定義 

‑製品属性に関するコード(色相，サイズなど) 

‑ビジネス取引と関連して情報のコード化が必要な部分のコード定義 

‑現在企業でコード化されて使用されている情報コード定義   

3)国際的に使用されているコードの定義 

‑国コード(ISO3166 参照) 

‑場所識別コード(UN/LOCODE 参照) 

‑通貨コード(ISO4217 参照) 

‑運送関係コード(UN/EDIFACT Code List 参照)   

4)上で使用されているコードもワークシートに提案されたコード表に合わせてコードを管理し，公開して 部外者にも充分に参照できるようにして，これに対するコメントも受けられるようにする。 

2)ドメイン分析 

‑ドメインの範疇をビジネス領域，プロセス領域，ビジネスプロセスで分ける (ワークシートで具体的 方法を提示) 。 

（5） 要求事項分析 1)目的 

‑B2B プロジェクトに対するユーザが明示した具体的な使用者の必要要件などを確保するためのもので ある。 

2)基本活動および遂行課題 

‑B2B プロジェクトの目標および範囲 

‑各ユースケースに対する必要要件等を把握すること(必要要件リスト) 

‑各ユースケースに対するアクティビティダイアグラムを作ること 

‑ビジネスエンティティ等を探すこと   

（6） 分析 1)目的 

‑ビジネス必要要件などをソフトウェア開発者と文書設計者が電子ビジネスソリューションを設計して 実行できるようにするためのスペックに転換させることである。 

2)基本活動 

‑B2B プロジェクトのビジネス取引に対するビジネス取引モデリングパターンを詳細に記述して語彙に 含まれたビジネス知識で概念的クラスダイアグラムを作り出すことである。 

（7） 設計 1)目的 

‑概念的クラスダイアグラムから情報モデルを開発 

‑ネットワークコンポーネント中でビジネスコラボレーションを記述するビジネスサービスビューを開 発 

‑ビジネスコラボレーションで交換されるビジネス文書(ビジネスアクションおよびシグナル)を記述す るクラスダイアグラムを開発 

‑情報モデルを業界間モデルで統合 

の 2 種類に分けられる。既存の UN/EDIFACT で開発する時にはデータ項目だけで構成された標準規格メッセー ジ(Standard Message)とメッセージ実装ガイドライン(MIG: Message Implementation Guideline)を開発しな ければならなく，すでに UN/EDIFACT 方式の開発方法と関連しては EDI メッセージ設計規則があるので，当ガ イドラインではこれは扱わずに EDI メッセージ設計規則を準用することを勧告する。 

XML フォーマットとして開発する時には 2 種類の方式に分けられ，コンポーネント方式の電子文書開発とマ ッピング方式の電子文書開発がある。 

（マッピング方式：CII または UN/EDIFACT などを単純に XML にマッピングしたもの） 

コンポーネント方式の電子文書開発はebXML のコアコンポーネントスペックによって開発する方法を当ガイ ドラインでは推奨し，詳しい開発指針は，別な開発指針で詳細に扱うこととする。マッピング方式の電子文 書開発はいろいろな標準の混在と準用に適する国際標準が存在しないため，この開発指針を準用することを 推奨する。 

また XML 電子文書開発をするに当たって先行的に決めなければ成らないことは XML フォーマットを DTD にす るのか XML Schema にするのかを決定しなければならない。下の表にDTD と XML Schema の比較分析表を簡単 に示したが，事業推進目的や計画によって使用者が選択的に適用しなければならない。 

  XML Schema  DTD 

概要  ‑2001 年 5 月，W3C 勧告となった。 

‑現在国際的に XML Schema の使用が大き な潮流になっていて，多くの XML 関連 機関や企業で XML Schemaを使用してい る。 

(ebXMLの場合電子文書やコンポーネント を XML Schema で開発することになっ た。) 

‑1998 年 2 月 W3C 勧告案で XML1.0 採択， 

現在 XML1.1 バージョン。 

‑文書型定義(Document Type Definition) 

‑現在国際的な潮流を見ると DTD で規則や，マッピ ング規則，メタモデルを構成するのに数多く使 用されている。 

長所  ‑ネームスペースのサポート 

(同音異義語で使用されているタグ名 の区別が可能) 

‑広範囲なデータタイプ支援 

(数字，文字など多様なデータタイプを支

‑開発しやすさ 

‑XML DTD の標準が出てから古いので，XML パーサ ーが数多く出ていて，安定している。 

‑DTDファイルの容量が小さくてシステム負荷に影 響が少ない。