UTI UML教育研究所
トップページ> 読み物> コラム> 続はじめるUML 第6回
はじめる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 第6回
2006.8.1 掲載
UMLによるシステム分析
前回はインターメディエイト受験の体験記をテーマにお送りしましたが、今回は連載 第2回「UMLによる業務分析」、第4回「UMLによる要求分析」に引き続き、ケーススタディによるUMLを用いたシステム分析をお届けします。

ここまでの業務分析と要求分析の結果から、システム導入後のビジネスプロセスと、その上で利用されるシステムに要求される機能、システム化範囲が明らかになりました。
開発の流れの一例としては、この後、ユースケース単位に詳細化を行い、オブジェクト間の相互作用や、コンポーネントを明確にします。また、各ユースケースの分析結果から全体のクラス図を作成し、ユースケースを跨ったオブジェクトの状態遷移をステートマシン図によって明らかにすることも行います。
今回は、明らかになった要求を実現するために必要なシステムの構造について、オブジェクト図と分析クラス図を用いて表してみます。

◇オブジェクトの抽出
まずは、業務分析で作成した概念クラス図などの参考に、ユースケース単位に、ユースケース記述から想定されるシナリオから具体的なオブジェクトとなるような名詞を抽出します。外部システムを表す語などは、システムを構成する要素となりませんので、オブジェクトの候補から除外することができます。
その結果、オブジェクトの候補は次のようになります。

[オブジェクトの候補]
請求担当者、請求情報、ダウンロード

実際の開発では、もっとたくさんのオブジェクトが抽出され、同じ意味の名詞が重複することもありますので、名詞の意味に応じたグループ(人、場所など)ごとに分類しながら整理していき、用語の統一なども行うのが良いでしょう。

◇オブジェクト図の作成
オブジェクト候補を抽出した後は、関連あるオブジェクト間にリンクを張り、オブジェクト図を作成します。そして、ユースケース記述の内容から具体的な属性の値を想定して、各オブジェクトの属性値を埋めていきます。その際、請求情報から請求明細オブジェクトを分けて、別のオブジェクトとするようにしました。

図:オブジェクト図>>画像を大きく表示

◇分析クラス図の作成
オブジェクト図を作成した後は、その内容をより抽象化した分析クラス図を作成します。分析クラス図はシステムの静的な構造を表現します。初期の段階の分析クラス図では、属性だけを記述し、操作はまだ記述しません。属性の型や可視性なども後から明確にする予定とします。従って、分析クラス図はクラス名や属性、関連だけが表現されたシンプルなものとなります。

図:分析クラス図>>画像を大きく表示

今回は1つのユースケースを対象に分析クラス図まで落とし込みましたが、実際の開発では、システムに要求される全てのユースケースが対象となります。従いまして、ユースケースごとに作成される多数の分析クラス図を、最終的には、マージして1つの分析クラス図を作成することができるでしょう。
また、この段階では、まだ実装言語などのプラットフォームに依存しないモデル(PIM: Platform Independent Model)としてのクラス図やコンポーネント図、相互作用図、ステートマシン図などを作成します。次回のシステム設計では、プラットフォームに対応するモデル(PSM:Platform Specific Model)として、実装言語においての型などを適用したクラス図、実際の配置を意識したコンポーネント図、配置図、ユーザインタフェースの実現方法などを反映した相互作用図などを記述していきます。

次回はネットワーク管理者による受験体験記を、その次の回でケースタディのシステム設計工程をお送りします。

<コラム>
このコラムでは、バージョンアップしたパターンウィーバーの新しい機能について紹介しています。
今回紹介するのは、モデルをシステムのビューごとに管理できるビュー管理機能です。モデリングを行う際は、システムを静的側面や動的側面などの、いくつかの視点でモデリングを行うことで、高品質なシステムを開発することができます。ビュー管理機能のビューとは、モデルを作成する際の視点のことを表し、パターンウィーバーでは、標準で「ユースケースビュー」、「設計ビュー」、「配置ビュー」が用意されています。また、独自のビュー(カスタムビュー)も定義することが可能です。このビュー管理機能により、各ビュー配下に作成を許可するダイアグラムやダイアグラムの要素を制限できますので、プロジェクトメンバー間で統一されたモデルの作成が可能となります。

図:ビューによる管理

図:ビューのツリー上での制限


■筆者紹介
株式会社テクノロジックアート テクニカルデプト システムコンサルタント
勝浦 正博/Masahiro Katsuura

パターンウィーバー(PatternWeaver) ver2.1
さらに使いやすく!
  • 名前空間(ネームスペース)の管理機能を搭載
  • 各種環境設定(デフォルト設定)が可能に
  • モデルのビュー(視点)管理機能を搭載
  • 最新Eclipseにも対応
  • Eclipse3.1.1へ対応
  • 組込み系ユーザにも対応
  • 状態遷移表の機能を搭載
  • C++ソースコード生成プラグイン
●商品に関するお問い合わせ
株式会社テクノロジックアート
e-mail : pw@tech-arts.co.jp
http://pw.tech-arts.co.jp/