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

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

日本のWebはGoogleとかじゃなく、「スナッコまこ」を目指しているってことよ!(その2)

2009-06-19 16:49:26 | Weblog

 まえに、梅田氏の「日本のWebは残念」の話に関して、そもそも、日本の文化と、アメリカなんかの文化が違い、
アメリカは、文書なんか中心の分野だから、論文公開や議論のためにwebを使うということが広まるけど、
日本の場合、「会って信用する」という分野がまだ強い(メールで意思疎通より)っていう話を書いた

 日本の場合、そういった、論文とかの公開は、既存の学会、国際会議でよいと考える人が、多いと思う。
 素人が来て、いろいろ意見言っても、混乱するだけだしねえ。。。生産的ではない。
 知っている人が、生産的に活動するには、やっぱ、集まってやるのがよくて、そーいったメディアである、
学会、国際会議がある限りは、わざわざ、Webでやるのも。。。っていう部分があると思う。
 あるメディアがあると、新しいメディアのほうがよくても、一般にすぐには広まらない(地デジとか)

 一方、日本には、こーいった一般の人同士が、水平的な展開(=上ではなく、横のつながり)で、情報を交換する方法は、あったけど、乏しかった。たとえば、「ここのお店はおいしいです」、「このソフトのインストール方法」などは、学会で議論されることはなく、頭のいい人、上の人にとっては、不要な情報かもしれないけど、一般の人には、必要な情報で、このような情報を交換する場は、Web以前は、パソコンやネットの掲示板しかなかった。
 しかし、掲示板は議論になってしまうので、議論したくない、個人的感想を書きたい人は、そんな情報をかく場所がなかった。

 一般の人にとっては、学者の理論などは、まず普通の生活では不要で、多くの人に必要な情報は、このような「ここのお店はおいしいです」、「このソフトのインストール方法」だった。そこで、Web、ブログが出たとたんに、これらの情報が、Web、ブログで広まった。

 つまり、日本において、学者さんや頭いい人のメディアはすでに存在していたので、Webというメディアは、まだ浸透していない。
 一方、一般の人に必要な情報は、それを交換する手段がなかったので、ネットが出てきたとたんに広まった

 ってことになる。

 では、一般の人が必要とする情報を交換する手段はなかったのか?っていうと、あった。
 それが、放送だった。
 ところが、放送は、Webが出てきたことにより、いままでの展開をすることができなくなってきた。

 そのことについては、その3で書こうと思う。


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

UML等各種ダイアグラムのエラーチェック体系化(その4:Strutsによる開発のダイアグラム関係)

2009-06-19 12:56:11 | Weblog

シリーズ、 「UML等各種ダイアグラムのエラーチェック体系化」です。
 前回ではダイアグラムの検証法について、UML→Strutsによる開発を例に話すため、まず、開発の流れを書きました。こんなかんじ。
(1)登場人物の整理

(2)登場人物にかかわる業務の流れを確認

(3)そのうち、コンピューター化する範囲を確認
     →ここで機能がでてくる

(4)機能ごとの入出力確認

(5)画面入出力から永続性項目取り出し(変換)→正規化→DB定義作成

(6)画面からフレームワーク決定→クラス決定

(7)画面遷移図、画面一覧→ActionForm,Action決定

(8)ActionForm,Action決定→struts-config.xml

(9)プログラミング

(10)テスト

(やっぱ、テストをいれました。その代わり、単体とか結合とか分けずに、単純にテスト)

今回は、この各工程で使われるダイアグラムの話。




■ま、結論から言うと・・・

こんなかんじかな・・・
(1)登場人物の整理
 ・組織図

(2)登場人物にかかわる業務の流れを確認
 ●アクティビティ図
 (または、・業務流れ図)

(3)そのうち、コンピューター化する範囲を確認
 ●ユースケース図
 ・ユースケースシナリオ
 (非機能要件まで考えるなら・i*など)

(4)機能ごとの入出力確認
 (・業務流れ図、・DFDなど)

(5)画面入出力から永続性項目取り出し(変換)→正規化→DB定義作成
  ・ER図
  ・DB定義書
  ・ファイル定義書

(6)画面からフレームワーク決定→クラス決定
  ●クラス図

(7)画面遷移図、画面一覧→ActionForm,Action決定
  ・画面遷移図
  ・画面定義書

(8)ActionForm,Action決定→struts-config.xml
  
(9)プログラミング

(10)テスト
  ・テスト仕様書

のちのちの理論を展開していくと、ダイアグラムも表も、抽象化して考えた場合、さほどの意味がなくなる。
(具体的には、表における正規化理論と、同じような正規系をダイアグラムでも行え、
 その結果、表も、ダイアグラムも同様のテーブルに展開できる)

そこで、図(ダイアグラム)や表について、
UMLで出てくるものについては、●、
そうでない図表は・
をつけてみた。なお、ソースコードに関しては、ここでは書かれていない。




次回は、これらの図表が、どのような関係を満たしていないといけないか、その2で記述した内容を元に、具体的に考えてみよう。



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