会話による ソフトウェア工学の開発実践06 - コンテキスト図とコンセプト図

単語

ポイント

• 見えなくなる恐れがありますが、… → 担心…会看不到了。

• 感じはつかめましたが、… → 抓到了感觉（我大概知道了，但是）。

• それが良いでしょう。 → 那样就可以了吧。

• コンテキスト図

• オブジェクト指向技術

• コンセプト図

• シナリオ図

会話

会話の背景

• システム分析段階ではユースケースを作成することが中心的な作業であるが、しかしながら、ユースケースだけではうまく表現できない部分も相当ある。たとえば、システムの全体に関する概念や機能、また外部との情報交換など。
• それに対していろいろな手段がある。ここではコンテキスト図やコンセプト図を紹介する。

登場人物

• 近藤：システムアーキテクト
  鈴木：開発チームリーダー
  山田、田中：開発チームメンバー

会話内容

• 鈴木：

  • こんにちは。
  • これまでに、皆さんにユースケースを書いてもらいました。大変お疲れ様です。
  • 何か問題があるでしょうか？我々はどう対処すればいいか、などを議論してもらいましょう。

• 山田：

  • そうですね。
  • ユースケースの書き方はなんとかわかってきましたが、具体的なユースケースを書くと、システムの全体に関する概念や機能などが見えなくなる恐れがありますが、それに対して何かいい方法があるでしょうか？

• 鈴木：

  • なるほど。それについては、システムアーキテクトの近藤さんに、説明してもらえますか？

• 近藤：

  • はい、まず、よくやっている方法はユースケースリストです。
  • すなわち、一つの画面（図形の方法）また一枚のページ（テクストの方法）で、全てのユースケースのタイトルを番号で関係を付けながら、集めてリストしておきます。

• 山田：

  • OK、分かりました。
  • もう一つは、実際的な現場のユーザーには、データの流れを表現していないユースケース図は、直観的に理解しにくく、データの流れを表すDFDのような設計図のほうがわかりやすいではないでしょうか？

• 田中：

  • すみませんが、DFDとは？

• 鈴木：

  • DFD は Data Flow Diagram の略です。即ち、データの流れを表すためのダイアグラムです。

• 近藤：

  • そうですね。一部のオブジェクト指向の本によると、DFD などはオブジェクトの概念とは反対のものなので、あまり使わないように薦めています。しかし、私の経験では、それは参考にはなりますが、まったくその通りにやる必要はかもしれませ。
  • ユースケース図は、やはり開発するシステム機能に早く集中する傾向があり、開発対象とするシステム外のほかのシステムや要素とのつながりを漏らしてしまうことがあるようです。また、ユースケース図はシステムの範囲を決めるべきだが、システム開発の初期では、範囲ははっきり決めるのはなかなか難しいこともよくあります。

• 山田：

  • そうですか。

• 近藤：

  • そのため、全ての人が理解できる、システムを一枚の図で表すようなものが必要です。これにはコンテキスト図が向いています。ここでいうコンテキスト図は一種の DFD ですが、システム外のデータのやり取りのみを記述し、システム内部のデータについては何も記述しないものです。
  • そうすると、この前言ったように、ユースケースが顧客とのコミュニケーションに使われるというのとちょっと矛盾するように思われますが、やはり現実には、同じようなものの違った表現が必要です。
  • また、コンテキスト図は、ユーザー側の企画書などにすでにある場合は、それをチェックして、開発側で流用できるケースもあると思います。

• 山田：

  • どうもありがとうございます。コンテキスト図に関しては分かりました。
  • どころで、各ユースケースで出てきた概念や名前など名詞は、これからはクラスになると聞きましたが、そうでしょうか？

• 近藤：

  • それの答えはYesでもありNoでもありますね。というのは、各ユースケースで現れた名詞はクラスになる可能性が十分ですが、必ずクラスになるかどうか、今の時点ではまだわかりません。そのため、コンセプト図の導入することが必要だと思います。

• 田中：

  • コンセプト図とは？

• 近藤：

  • コンセプト図は一種のクラス図とも言えますが、分析レベルのものです。普通のクラス図ではクラスの属性と操作などの記述が必要ですが、ここでは主に名前だけを整理した図になります。
  • というのは、基本的にはユースケースから出てきた名詞を整理したうえで、重要な意味を持つ名詞、あるいはオブジェクトらしい名詞をリストし、それらの名詞の間の関係をつけてみます。その目的は、重要な概念を見つけ、重要ではない概念を捨てることです。
  • コンテキスト図と同じように、できるだけ1枚の図でこのシステムの重要な概念をお客様に見せたほうがいいと思います。

• 田中：

  • 分かりました。我々もコンセプト図を書きましょう。
  • それと、ユースケース記述を表すために、シーケンス図を使うことができるでしょうか？

• 近藤：

  • そうですね。クラス図と同じように、シーケンス図でも分析レベルと実装レベルの区別があると思います。
  • 一般的に言うと、実装レベルのシーケンス図はオブジェクト間のメッセージ通信です。しかし、分析段階ではオブジェクトそのものがまだはっきりしていないので、オブジェクト間のメッセージ通信より、システムの流れを表します。言い換えると、ユースケース記述の代わりに、図で表現するものです。
  • われわれは、このようなシーケンス図をシナリオ図と呼んでいます。シナリオ図の主な特徴は明確的なオブジェクトは持っていません。

• 田中：

  • 大体、感じはつかめましたが、まだ十分に理解できていないようです。例で説明してもらえますか？

• 近藤：

  • 分かりました。例えば、“車両の注文書"を作成するというユースケースでは、その流れは、以下のようになっている。
  • 1．お客様の注文情報を入れて、
  • 2．システムがデータベースから対応する見積情報を引き出し、
  • 3．その見積情報に基づいて注文書のデータをまとめ、また今回注文の情報を付け加え、
  • 4．最後にそのお客様の注文書を作成し、
  • 5．確認して上で、印刷する。
  • このような流れをシナリオ図で表すことができます。

• 田中：

  • 分かりました。これからは、我々もユースケースリスト、コンテキスト図、コンセプト図、および一部のシナリオ図を書いてみましょう。

• 鈴木：

  • それがいいでしょう。がんばりましょう。

× WZhong

真诚赞赏，手留余香

2元 5元 10元 50元 100元 任意金额

2元

使用微信扫描二维码完成支付

• ← Previous Post
• Next Post →