ウィリアムのいたずらの、まちあるき、たべあるき

ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです(たま~にコンピューター関係も)

「Google Voice」って、なに?音声電話サービス??

2009-06-26 22:40:39 | Weblog

ここのニュース
グーグル、音声電話サービス「Google Voice」の一般提供を開始
http://headlines.yahoo.co.jp/hl?a=20090626-00000000-cwj-inet

によると(以下斜体は上記サイトより引用)


 米国Googleは6月25日、同社サイトで3月以降に音声電話サービス「Google Voice」に登録したユーザーを対象に、同サービスの提供を開始した。


ほお・・・で、「Google Voice」って、なに?


 Google Voiceは、Googleが2007年3月に買収したGrandCentralのサービスをベースにした無料の音声電話ソフト。


って、ここまできくと、無料のIP電話??ってかんじだけど・・・

ユーザーはGoogleから招待状を受け取ると、Google Voiceの電話番号を選択することができる。この番号に電話がかかってくると、所有するすべての電話に着信するようになる。

うん、なんか違う・・・??・・・よくわからん・・・


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

ことばと業務流れ図、UML、ユースケースシナリオの関係

2009-06-26 15:59:30 | Weblog

 前の話に関連して。
 業務流れ図を書く場合、結局ヒアリングして、図を描くことになる。
 この場合、どのようなことをヒアリングすれば、業務流れ図を書くことが出来、また、プログラミングまで落とし込めるのか?

 よく、5W1Hが大事といわれる。

 いつ
 どこで
 だれが
 なにを
 なぜ
 どのように

このうち、業務流れ図では、

 いつ
 だれが
 なにを
 どのように

を担当する。これについて、ちょっと説明する。




■業務流れ図で、表現するもの

●いつ
 これは、何時何分何曜日、地球が何回、回ったとき!
 っていうのではなく、この作業が終わったら、とか、
 こういった場合というような、状態(ステータス)や、
 手順として、表現される

●だれが
 スイムレーンになる

●なにを
 入力になる

●どのように
 出力になる。普遍的には、「入力を出力に変換する」=どのように
 ということになるが、文脈に応じて「入力を出力に変換する」が、
 受注するとか、生産するとかに変わる。
 しかし、出力がないと、これが定義できない。

これらのものを業務流れ図を書くときに使う。




■業務流れ図で、表現しないもの

●いつのうち、「何時何分何曜日、地球が何回、回ったとき!」
 これは、非機能要件になってくる。毎日起動するとか・・・

●どこで
 これが決まっちゃうと、クラウドとかは、できませんな(^^;)
 クラウドなんか、どこで処理しているかわかりませんから・・・

 ・・・ただ、非機能要件で指定があるときもある。

●なぜ

 なぜ、この業務を行うのか・・・

 ・・・うーん、奥が深い・・・

 首が切れないから。。。とか・・・

 こんな場合は、非機能要件をみてもわかんないこともあるが・・・
 ま、普通、非機能要件?




■このほかに・・・

 たとえば、5W2Hとか言う場合、How much,How manyというのがある。
 How Muchである、金額およびそれに伴う納期は、非機能要件、
 How manyである、1時間に何件、何秒以内に返ってくるっていうのも、非機能要件になる。




■UML、ユースケースシナリオの関係

 UMLのアクティビティ図、ユースケース図は、おもに、「だれが、どのように」を、
とくにデータの裏づけがなく、「どのように」を議論する。
そこで、議論はしやすいけど、実現性の矛盾チェックをしにくくなり、
実装できないようなものが出来てしまうことがある。

 その暴走をおさえるために、ユースケースシナリオで具体化するが、
このとき、5W1Hを抑えれば、業務流れ図と同じレベルの精密さになり、
プログラム化可能


・・・だが、ユースケースシナリオは、UMLの「図」じゃないし、

業務流れ図と同じレベルの精密さになることより、業務流れ図を書いてしまったほうが
早い気がする・・・


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

UML等各種ダイアグラムのエラーチェック体系化(その8:ドキュメントの一貫性チェック)

2009-06-26 12:06:49 | Weblog

シリーズ、 「UML等各種ダイアグラムのエラーチェック体系化」です。
 前回は業務流れ図をとりあげ、
 用語定義→業務流れ図→画面定義書、帳票定義書→ER図→ファイル、DB定義→(クラス図)→プログラム
 という形で、プロセスおよびデータの一貫性チェックができるということ、また、業務流れ図を変形させて、多様なダイアグラムを書き直せることを示しました。

 今回は、業務流れ図の粒度という話と、粒度間・前後工程間の一貫性、そして、一貫性チェックのために何が必要かという話を書きます。




■業務流れ図の粒度

 業務流れ図は、大雑把にもかけますし、細かくもかけます。
 スイムレーン=会社のところに、業務=システム全体として、書こうと思えばかけちゃうわけです。
 (DFDのコンテキストダイアグラムと同じ。おもに、外部データ、登場人物を明らかにするのに使う)
 もちろん、これらを細かく書くことも可能なわけです。

 では、どこまで細かく書けばいいか?

 基本的に、

・後工程の入力になるために、前工程としては、どこまで記述しないといけないか?

 と考えると、後工程は、画面定義書、帳票定義書となりますので、

  どの画面定義書をそろえればいいかわかる=画面名記述
  どの帳票定義書をそろえればいいかわかる=帳票名記述

 が記述されていればいいことになります。つまり、入力時における画面名、出力における画面名、帳票名が特定できるレベルにまで業務が細かくなっていること、つまり、
 「●●画面を入力とし、XXさんが、■■すると、◎◎(帳票・画面)を出力する」
というレベルにまで細かくなっていればいいことになります。




■一貫性

 そうすると、大雑把に書いたものから、細かく書いたものまで、業務流れ図が出来ることになります。

 これらの間で矛盾がないかどうか(大雑把に書いたところの入力画面が、詳細化したところで、まったく現れないなど)を確認しないといけません。

 また、前から書いているように、工程の前後間のチェックもしないといけません。

 たとえば、「業務流れ図で出てきた画面は、後工程の画面定義で、画面内容が、定義されていないといけない」とか、そんな話です。

 これらのチェックを一貫性というとすると、一貫性には、

・同じダイアグラムにおける、粒度間での一貫性
・異なるダイアグラムにおける、前後工程間の一貫性

の2つの側面があり、どちらも、ここで書いた

・ダイアグラムの入力に関するチェック
   →入力時矛盾チェック
     =入力データが前工程で作成されていて、利用可能になっているか

のチェックが必要となります。これを、ここでは、一貫性チェックと呼びます。




■一貫性チェックのために何が必要か

 一貫性チェックは、したがって、

・あるダイアグラムを書く工程において、必要なデータがそれまでの工程でダイアグラム等で明記されているか

ということを調べればよさそうです。

明記されているか=存在しているかのチェック

ということになります。

 それには、いろいろなチェック方法がありますが、ここでは、こんな戦略をとります。

・すべてのダイアグラムをRDBに入れます。
・必要なデータがそろっているか=そのRDB内に必要なデータが存在するか?
  ということになるので、
・必要なデータをSQLで検索をかけます。
  selectで、存在するかどうか確かめる。

 そうすると、問題は、

「すべてのダイアグラムをRDBに入れることは可能なのか?」

ということになります。

その方法について示そう!というのが、このシリーズの1つのテーマです。
次回から、それについて説明します。


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする