astah*で業務をまとめ、プログラムまでのトレーサビリティを取る－その８ ＥＲ図

　シリーズastah*で業務をまとめ、プログラムまでのトレーサビリティを取るのつづきです。

　エンタープライズ系の開発をトレーサビリティをとって行う流れをまとめるとこんなかんじ。

　　・ユースケース図
　　　　　↓
　　・アクティビティ図
　　　　　↓
　　・（ユースケースシナリオ＝astah＊にない）
　　　　　↓
　　・アクティビティの構成を示したクラス図
　　　　↓　　　　　　　　　　　↓正規化
　　　画面定義、帳票定義　　　ＥＲ図

前回は、画面定義、帳票定義の話をしました。

今回は、ここから、ＤＢ定義、ＥＲ図作成についてです。

---

■変換のしかた＝正規化

といっても、それって、画面項目から、保存する必要のある項目を抜き出し、
テーブルに適当に分けなさいということなので、

正規化しなさい

といっていることといっしょです。

つまり、

１．画面項目定義から、保存すべきデータを取り出す。
　　既存の項目と関連ある項目は、まとめていく。

２．その中で、繰り返し要素があったら、分ける：第一正規形

３．そうしてできたまとまりをテーブルとして、
　　そのテーブルの主キーをきめる。
　　主キーが複数項目からなるとき、その項目の一部をきめると、
　　他の項目も決定してしまう場合、それは別テーブルにする
　　：第二正規形

４．主キー以外で、ある項目が決まると、
　　他の項目も決定してしまう場合、それは別テーブルにする
　　：第三正規形

という形でテーブルをわけ、ＤＢ定義とします。

---

■ＥＲ図

　ＤＢ定義ができると、テーブル名をエンティティとみなすことで、ＥＲ図がかけます
　（みなしていいのか？という問題はあるが）
　リレーションは、外部参照しているところで、
　カーディナリティは、主キーがあるほうが１、そうでないほうは多（または、０、１）
　です。

---

■astah*の図

　astah*のプロフェッショナルには、ＥＲ図は入っているのですが、
　今回使っているのは、コミュニティ版で、それには入っていないので、
　省略します。

---

■このあと

　画面定義書から、フレームワークによって、画面部分
　ＤＢ定義をもとにＤＡＯ部分

が生成され、あとはそれをつなぎます。どこに書けばいいかは、前もってクラス図に描いてあります。

ということで、プログラムにつながってくるのですが、
この部分は、フレームワークや言語によって、ちがってくるので、省略します。

次回は、ステートチャート図

WekaでTwitterを分析して、読むべきものだけを抽出する。その１ 概要

　うん、シリーズにしないとやらなそうだし、ちょうど時間ができたので、
　「WekaでTwitterを分析する」というシリーズをやろうと思います。


＜＜目標＞＞

ＴＬをまとめて落としてきて、あるプログラムに掛けると、読むべきつぶやきが抽出されてくる。 　この「あるプログラム」を作成する。

＜＜方針＞＞
予測に、ロジスティック曲線を使います。

１．サンプルとなるいくつかの「つぶやき」を抽出して、
　　読むべきものと、読まなくっていいものにわける。

２．そのつぶやき全部をmecabで形態素解析して、
　　頻度のたかい名詞、動詞を抽出する

３．各つぶやきが、２の名詞、動詞を含んでいるか、それと
　　リンクを含んでいるかどうかチェック

４．各つびやきの、３の状態＋１の読む読まないをまとめた表を作成

５．それをARFF形式にする

６．Wekaで読み込み

７．ロジスティック回帰でいいかどうかわかんないけど、
　　ロジスティック回帰にしちゃえ（＾＾）分析start!

８．なんとなーくいい予測値の組み合わせを見つけ、
　　Coefficientをだして（つーか、Ｗｅｋａが出してくれるので）
　　その値で回帰式を作成

９．以降、ＴＬのつぶやきを、その回帰式に代入し、
　　よむべきか、よまないでいいか決定！


ま、こんなかんじでできそうだよね！
２．３は、やりすぎかにゃー。ある程度、言葉をこちら側でしぼったほうがいいかにゃー。