Transcript CBSDとDOA
DOA UML ComponentsとDOAの比較 OOAとほぼ同じフロー。 コーポレート 概念データモデル UML Components 業務フロー 要件定義 ビジネスプロセス ト ッ プ ダ ウ ン ビジネス概念モデル システム構想 ユースケース 概念データモデル 論理データモデル （トップダウン） 仕様 ビジネスタイプモデルの 作成 ビジネスインタフェースの 識別 システムインタフェースの 識別 インタフェースと操作の洗 練 コンポーネント仕様とアー キテクチャの洗練 コンポーネント仕様 操作と事前／事後条件の 定義 コンポーネント仕様とアー キテクチャ 正規化 論理データモデル （ボトムアップ） CRUD分析 DFD図 コンポーネント相互作用 インタフェース情報モデル の定義 マージ （ボトム アップを ベースに） コンポーネント識別 初期のコンポーネント使用 とアーキテクチャの策定 ビジネス操作の識別 画面・帳票 ボ ト ム ア ッ プ ユースケース分析と等価 ビジネス概念モデル導出と等価 ■プロセス上の違い ・DOAのトップダウンのアプローチはOOAのデータモデリングとほぼ同じな ので問題がなさそう。 ・DOAではボトムアップをマージする形で進めていく。ここはかなり現実的な 点である。日本での開発では画面や帳票が先行してでてくることが多い（EA のような企業レベルのデータモデリングをせずに、小手先の既存業務フロー のシステム化が多いから？）ため、ボトムアップ手法が非常に有効。 ⇒画面や帳票にあたるものがユースケースでは？ユースケースで等価な検 討が可能か。 全体的にプロセスとしての等価性は既に確保できているように見える。 最初にDOA、OOAを意識せずに作成した概念モデル、論理モデルを元に 「オブジェクト世界での表現」「RDBの表現」への変換を定義しておけば、 早い段階でERモデルも明らかになるのでは？ 概念モデル A 1 1 B A 1 * B A * 1 B A * * B ER サ で並 ブ も行 で 現し オモ実て デ がブルは進 ジ 多 をこめ いェ クメんる トイな？ モン感大 デ、じ変 ル 。？ 各多重度ごとのERモデル、オブジェクトモデルで の表現方法はORマッパーなどの普及でだいた いパターン化されている。 論理ERモデル オブジェクトモデル （インタフェース情報モデル） 物理ERモデル Java実装のデータモデル （インタフェース情報モデル） UML ComponentsではERは後付け？性能は 大丈夫なのか？オブジェクトモデルだけのトッ プダウンで考えると、知らぬ間に「正規化し過 ぎ」の現象が起きたりしないか？ メインをオブジェクトモデルで考えつつも、、論 理ERモデルのレベルで早期にERモデルを作 成し、非機能要件を満たせるか確認する必要 があるかもしれない。 ※ ERモデル → オブジェクトモデル というのが通例なので、O-Rマッピングで大きく 苦しむことはないが・・・・・ UML Components で オブジェクトモデル → ＥＲモデル を最後にどかんとやったときに本当にうまくでき るのか心配な感じがするので、こういうことを考 えています。 ■モデリング上の違い（インピーダンスミスマッチなど） ・DOAにおける正規化のプロセスは、トップダウンでモデリングするOOAで は自然に組み込まれていると考えられる。 ・オブジェクトにおける集約や関連を、RDBにおける外部キー制約ととらえれ ばほぼ大丈夫？オブジェクト世界の汎化／特化などができてた時に考慮す る必要がありそう。 ・UML Componentsではデータモデルのやりとりを「id」をベースにやるので、 この点もRDBにおける主キーに置き換えやすく親和性は高いと考えられる。 ・オブジェクトモデルとRDBの違いはS2JDBCなどO-Rマッパーを使用すれば 実装上の手間は減らせる。 成果物の俯瞰 UML Componentsの簡易化 要件定義 ビジネスプロセス 不要 ビジネス概念モデル システム構想 不要 ユースケース図 ユースケース記述 仕様 コンポーネント識別 ビジネスタイプモデル図 ビジネスタイプモデルの作成 ビジネスインタフェースの識別 ビジネスインタフェースモデル図 システムインタフェースの識別 システムインタフェースモデル図 初期のコンポーネント使用とアーキテクチャの策定 中間生産物 不要 コンポーネントアーキテクチャ図 コンポーネント相互作用 ビジネス操作の識別 相互作用図 インタフェースと操作の洗練 洗練したインタフェースモデル コンポーネント仕様とアーキテクチャの洗練 コンポーネントオブジェクトアーキテクチャ 不要 不要 コンポーネント仕様 インタフェース情報モデルの定義 操作と事前／事後条件の定義 コンポーネント仕様とアーキテクチャ インタフェース情報モデル OCL ？ データモデルだけでよいのでは？ ビジネスIF、システムIF、両方必要か？ 機能仕様書の代替とする。 Seasar2を用いたアーキテクチャ ・画面入力項目 ・入力チェック SAStruts JSP N1 S2JDBC Form Entity 0…1 1 Action ・ユースケースと1:1 ・実行メソッド ・Service呼び出し ・画面遷移 ・セッション管理 1 N <<DI>> <<DI>> <<DI>> 1 1 Table 1 Logic <<DI>> 1 ・導出項目 ・区分値（定数） ・拡張プロパティ <<DI>> 0...1 Service <<DI>> <<DI>> N DTO ・画面出力項目 （読み取り専用プロパテ ィ） ・JSPと1:1＋α 1 1 Helper ・Entityと1:1 ・DBに関するロジック ・ビジネスロジック ・DTOと1:1 ・データ変換 UML Componentsを考慮 状態を持つのはActionが呼び 出すHttpSessionと、DBのみ。 性能的な実用性からビジネス 層はステートレス。 →クラス図に必要か？ ・画面入力項目 ・入力チェック SAStruts JSP N1 S2JDBC システム IF Form 0…1 1 ビジネス IF Facade Logic ・導出項目 ・区分値（定数） ・拡張プロパティ Entity 1 1 Table 1 <<DI>> 1 <<DI>> Action ・ユースケースと1:1 ・実行メソッド ・Service呼び出し ・画面遷移 ・セッション管理 1 N <<DI>> <<DI>> <<DI>> <<DI>> 0...1 Service <<DI>> <<DI>> N DTO ・画面出力項目 （読み取り専用プロパテ ィ） ・JSPと1:1＋α 1 1 Helper ・Entityと1:1 ・DBに関するロジック ・ビジネスロジック ・DTOと1:1 ・データ変換 ■アクセス方法の問題 UML ComponentsとDOAのビジネスインタフェースの切り方の違い（SELECTの場合） DOAとOOAのハイブリッドでよくあるパターン（トランザクションスクリプト） Reservation 予約詳細を取得する 予約詳細を取得する システムインタフェース ビジネスインタフェース SQL Hotel JOINを使った大きいSQL Customer UML Components での標準的なDBアクセス（ドメインモデル） ビジネスインタフェース IReservationMgt SQL 性能：高 再利用性：低 Reservation 予約詳細を取得する システムインタフェース ビジネスインタフェース IHotelMgt SQL Hotel ビジネスインタフェース ICustomerMgt SQL Hotel JOINにあたるデータの くみ上げはシステムイン タフェースがやる 性能：悪 再利用性：高 JOINを使わない小さいSQL ビジネスインタフェース＋SQLの粒度を小さくすることが再利用の肝と考えられる。DOAの大きいSQLでのアクセスパターンはビジネスインタフェースそのものの粒 度が大きくなるため、ビジネスインタフェースの再利用性が低くなる。 しかし、コンポーネントベース開発ではコンポーネント単位での再利用性が確保できればよいから、ビジネスインタフェース単体の再利用性にこだわる必要はないと も考えられる。 性能と再利用性のどちらを取るかのアーキテクチャの選択の一環とも考えられる。 なお、ここで想定する「よくあるSIerでの要件」としては、「既存業務など、項目が既に決まっている」「DB性能を求められる」などである。 ただし、コンポーネントベース開発で得られるメリットをDOAベースの手法でも得られる可能性は残る。 Reservation 予約詳細を取得する 予約詳細を取得する システムインタフェース ビジネスインタフェース SQL Hotel JOINを使った大きいSQL Customer なお、この場合、コアタイプの概念が崩れていることに注目する必要がある。本来、コアタイプごとに分割したビジネスインタフェースが一つになっている。 ビジネスインタフェースを、「コアタイプを中心に取り出すインタフェース」と定義しなおすと、ビジネスインタフェースの役割はシステムインタフェースに近く なる。 本来ビジネスインタフェースが担っていた役割は、その後ろにあるDAOが担い、一部のデータ組み合わせロジックはSQLに混入する。 DOAのパターンでは、システムインタフェースとビジネスインタフェースが1対1になりやすいため、この範疇だけだとシステムインタフェースは不要とも考 えられる。 その場合、1つのビジネスインタフェースとDAO群で1つのコンポーネントを構成するような形式になる。1ユースケースごとに1ビジネスインタフェース。結 局、ユースケースにかなり依存したモデルになってしまう。ただ、操作の粒度が大きいため、事前条件はOOAよりもシンプルになるのではないかと考え られる。 これでは、UML Components のメリットが得られなくなってしまう。何かよい解決策はないか？ （ユースケース依存になる弊害として、結局、再利用性が低くなる、ということ。とはいえ、DBとのやりとりを意識しているので、ビジネスインタフェースや DAOのメソッドの再利用はある程度見つけられる見込みはある。（現状やっている開発がこんな感じ。） 修了制作の方向性として、このようなよくあるDOAパターンとUML Componentsの違いを評価して、再利用性がどれだけ変わってくるかを評価して、 DOA側に倒れた現状の開発をよりOOA側に引き寄せる根拠とする案も考えられる。 UML ComponentsとDOAのビジネスインタフェースの切り方の違い（INSERT/UPDATE/DELETE/SELECTFORUPDATEの場合） ビジネスインタフェースからDAOをたくさん呼ぶ DOAとOOAのハイブリッドでよくあるパターン（トランザクションスクリプト） 予約詳細を取得する SQL Reservation SQL Hotel 予約詳細を取得する システムインタフェース ビジネスインタフェース SQL Customer UML Components での標準的なDBアクセス（ドメインモデル） ビジネスインタフェース IReservationMgt SQL 性能：高 再利用性：低 Reservation 予約詳細を取得する システムインタフェース ビジネスインタフェース IHotelMgt SQL Hotel ビジネスインタフェース ICustomerMgt SQL Hotel JOINにあたるデータの くみ上げはシステムイン タフェースがやる 性能：高 再利用性：高 INSERT/UPDATE/DELETEなどの更新系ではJOINなどはできないので、必然的にSQLの発行は分かれる（例外としてBulkUpdateなどはあるが）。 この場合は、1つのビジネスインタフェースで複数のDAOを呼び出して全て処理してしまうか、ビジネスインタフェースから分けるか、という選択になる。 SELECTと比べて、後者を選択できる条件は多い。 トランザクションスクリプトアーキテクチャとドメインモデルのどちらを選択すべきか、ソフトウェアパターンのアーキテクチャ評価の手法を使って ケースによる使い分けを検討するのはどうか。 評価軸： 規模、ＤＢアクセスの複雑さ、性能要件の厳しさ、該当コンポーネントの再利用見込み トランザクションスクリプト的なアプローチから始めると、ある規模以上になったときに、ビジネスインタフェースの実装が複雑に巨大になる、共 通化が困難、などの現状・ニーズがあるので、ドメインモデル的アプローチが必要になる損益分岐点のようなものがあるのではないかと推測 している。 課題 プロセス軽減化の方法は？ ERモデルとの関連は？ OCLをどの程度使うか？ アーキテクチャの選択は？ 「１システム」の定義は？