UTI UML教育研究所
トップページ> 読み物> コラム> 使えるUML 第2回
はじめるUML(全12回)
  はじめてみよう!
  モデル要素の整理整頓
  システム全体の構造(1)
  システム全体の構造(2)
  システム全体の構造(3)
  システム化対象の業務(1)
  システム化対象の業務(2)
  システムの動き(1)
  システムの動き(2)
  状態の移り変わり
  OCUPにチャレンジ!
  UML2.0総括(最終回)
続はじめるUML(全10回)
  使ってみよう!
  UMLによる業務分析
  営業職のOCUP受験体験記
  UMLによる要求分析
  インターメディエイト受験体験記
  UMLによるシステム分析
  アドバンスト受験体験記
  UMLによるシステム設計
  情報システム管理者が利用するUML
  続はじめるUML総括
使えるUML(全10回)
  使いこなしてみよう!
  物事を分けてとらえる
  コンポーネント図のいくつかの表現方法
  枠組みを使用してとらえる
  内容とその表現方法をわける
  パターンの表現
  続・パターンの表現
  モデルのモデル
  あいまいさを排除する
  「どのように(How)」から「何を(What)」へ
  大人のオブジェクト指向(最終回)
資格取得までのステップ
FAQ
教育コンテンツ
キャンペーン
ブックプラス
パートナープログラム
認定ユーザープログラム
メールマガジン登録
お問合わせ
使えるUML 第2回

パターンウィーバー(PatternWeaver) ver2.2
さらに使いやすく、新機能満載!
  • 多言語によるモデル開発をサポート
  • モデル駆動型のSOA(サービス指向アークテクチャ)をサポート
  • MS-Word形式へのドキュメント出力をサポート
  • RCP(Rich Client Platform)版の提供を開始
  • 洗練された各種ダイアグラム
  • 操作性の強化
  • リポジトリ(UML要素管理機能)の強化
  • ソースコード連携の強化

評価版がダウンロードできますので、ぜひお試しください。
http://pw.tech-arts.co.jp/download/community_edition.html

●商品に関するお問い合わせ
株式会社テクノロジックアート
e-mail : pw@tech-arts.co.jp
http://pw.tech-arts.co.jp/

2007.3.2 掲載
物事を分けてとらえる(続き)
今回も前回に引き続き「物事を分けてとらえる」をテーマにお送りします。複雑なビジネス領域や、高度な要求を実現するシステムの問題を解決するには、問題を分解してから解決方法を検討することが有効になります。その中でも「仕様と実現方法を分ける」と「論理と物理を分ける」は、UML2が特に得意としていることです。

◇仕様と実現方法を分ける(前編)
オブジェクト指向システムを設計する方法のひとつとして、CBD(コンポーネントベース開発)があります。システムをソフトウェア部品であるコンポーネントの組み合わせで構築することで、変更容易性や再利用性を高めることができる開発方法です。近頃のシステム開発、特に大規模システムでは欠かせない考え方になっています。また、最近注目を集めているSOA(Service Oriented Architecture)を実践する際にも有効なことから、再びCBDに焦点があてられているのをよく目にします。
UML2.0から加わったコンポーネント図は、EJB(Enterprise Java Beans)や.NETをはじめとする実装上の物理的なプログラム部品を表現する場合だけではなく、上流工程から論理的なコンポーネントを意識した開発方法論を採用する際にも活用できます。次の図はコンポーネント図で記述した簡単なコンポーネントの例です。

図1 コンポーネントとインターフェース
図1 コンポーネントとインターフェース

最初にコンポーネントは、そのコンポーネントが実現する仕様である提供インターフェースと、別のコンポーネントに要求する仕様である要求インターフェースで表現されます。この例では、「モーター管理」コンポーネントは「モーターを操作する」インターフェースを提供し、「速度を監視する」インターフェースを備えているコンポーネントを要求しています。

【ポイント】
・システム内部をインターフェースによって、複数のコンポーネントに分割する。

「仕様と実現方法を分ける」とは、インターフェースとコンポーネントを分けて考えるということです。こうすることで、システム内部のモジュール性を高めることができ、仕様変更の影響範囲が局所化されるなどの効果を得ることができます。変化の影響範囲を限定するという意味では、ドミノのストッパーに似ているかもしれません。ストッパーがなければ、作成途中に誤ってドミノが倒れ初めてしまうと、広範囲にわたり文字通りドミノ倒しに崩れてしまいます。
ここでの「コンポーネントに分割する」とは、大きな機能を階層的に機能分割していくというよりも、アーキテクチャを意識した分割を行うことを意味しています。インターフェースを定義し、コンポーネントを抽出する際に考慮する点としては、例えば次のようなものが考えられます。

  • 類似する複数のインターフェースに従ったコンポーネントを実現することで、コンポーネント内部で保持される情報や、行われる処理が共通化できるかどうか。
  • 機能要求にバリエーションが考えられるかどうか。
  • 機能要求による変化が発生しやすい個所を切り出せているかどうか。
  • 設計者及び実装者にアサインできる単位であるかどうか。
  • 別のシステムでも再利用できる部品であるかどうか。
  • パフォーマンスチューニングや、外部システムの利用、プラットフォームの変化などにより、差し替えが発生しうる個所であるかどうか。

インターフェースのことをコンポーネントの「仕様」と表現しましたが、他の言い方では、コンポーネントの「規格」と表現することや、コンポーネントが提供/要求するサービスととらえることもできます。先ほどの例のインターフェースを、ボール・アンド・ソケット表記から分類子表記にして、詳細を見てみましょう。

図2 インターフェースの詳細
図2 インターフェースの詳細

「モーター管理」コンポーネントは「速度を監視する」インターフェースに従ったコンポーネントを利用し、「メーター制御」コンポーネントはその実現方法を提供します。

「仕様と実現方法を分ける」ことで、別の実現方法のコンポーネントに差し替えたり、さらに追加のコンポーネントを接続することが可能になります。次の例は、アナログな速度メーターに加えて、デジタル表示を行う速度メーターを接続した例です。また、「デジタルメーター制御」コンポーネントは複数の提供インターフェースを備えています。

図3 コンポーネントの差し替え/追加
図3 コンポーネントの差し替え/追加

◇まとめ
今回は前回に引き続き「物事を分けてとらえる」をテーマに、インターフェースによって区切られたコンポーネントが問題を局所化し、より設計が行いやすくなることをお話ししました。しかしながら注意が必要なのは、物事には「さんまと大根おろし」「カモとネギ」のように、どうしても切っても切り離せないものがあるということです。そういった問題を無理に分けてしまうと、より問題が複雑になってしまうことがあります。別々に考えるべき問題なのか、別々にすべきでない問題なのかの見極めが重要です。
次回は「仕様と実現方法を分ける」の後編をお送りします。今回話題に上がりましたCBD(コンポーネントベース開発)に関する詳細につきましては、弊社テクノロジックアートで提供しておりますトレーニングコースや、コンサルティングサービスをご活用いただけます。


■筆者紹介
照井 康真/Koma Terui
株式会社テクノロジックアート テクニカルデプト モデリンググループ リーダー