ソフトウェア工学ネタで珍しく、ものすごいアクセスがあるようだ。
ソフトウェア工学ネタなら困らないので、今日も書いてみる。
そのうちアクセス減ったら、また止めるけど・・・
実はastahを使って要求から画面作成までを一気通貫（＆自動生成）する方法の論文が無料で見れる
http://blog.goo.ne.jp/xmldtp/e/c065809180323d35203281c33cf2be68
に書いた、その先・・・なんだけど、２つの方向がある
１つは、入出力項目から、ＤＢに行く方向、
もう一つは、要求文から一気に自動生成する方向。
上記の入出力項目からＤＢを生成する方法は、
佐藤正美,論理データベース論考―データ設計の方法:数学の基礎とT字形ER手法
ソフトリサーチセンター (2000)
に、確か出ていたかな・・・この本、はじめの数学は読み飛ばしていい。
あとのＴ字型ＥＲ図の作成手順からよみはじめる。
最近の佐藤氏の本は読んでいないのでわかんないけど、書いてあるのだろうか・・
ただ、ペーパーになると、はっきり書いてある論文は・・・みてないなあ・・
（ごめん、不勉強なだけかも）
実は、コンサルや実務家が本を書くのと、研究者が論文にするのには、
かなりギャップがある。
この前のastah使って・・で紹介した、小形先生、松浦先生の論文が出たのは、
２０１０年。
実務家の人が、それらしきことを言ったのは、
テクノロジックアート , C&R研究所 , 橋本 大輔, 長瀬 嘉秀,アッと驚く達人の技 UMLシステム設計実践技大全
ナツメ社(2003)
で、２００４年ごろ（本が出たのが２００３年１２月）
この本を見れば、ＵＭＬでどうすれば開発できるか、一通りわかる
（つまり、今なら１円＋送料で、ＵＭＬの開発の流れがわかる）
でもその本が出た後、日本人はヤコブソン大好きなので
（ヤコブソンも日本好きなんだよね）、ＩＣＯＮＩＸに行った。
また、実務では、ＲＵＰなんかの方法論も出たけど、
ＲＵＰは重くて、ＩＣＯＮＩＸには無駄もあって、
「UMLシステム設計実践技大全」の手法が圧倒的にわかりやすかったので、
この手法に落ち着いたのかな・・・
ただ、実務的には、論文に耐えうるものは出てなくて、
２０１０年のあの論文まで、待ったっていう感じかな・・
ここまで、数年の歳月が流れてる。
つまり、コンサルや実務家は、ラフな議論でいいので、
本が早くでる。
一方、論文、とくにフルペーパーになるのには、
ある程度厳密な議論と実証がいるので、時間がかかる。
この間、かなりギャップがある。
クラス図からＤＢ化の手法は、
現在、この時間のギャップのハザマにあるかんじかしらね。
一方、要求文から、直接プログラムを自動生成していく手法は、
研究者中心に活動してるけど、道半ば。
言語的に制限を加えたり、自然言語を構文解析したり。
ただ、構文解析の場合、形態素までに分けてしまうと、
文章の関連(係りうけ）とかが見えてこない。
さらに、複文・重文が作れちゃうと困る。
ってなってくると、係り受けが重要で、南瓜の出番なんだけど、
そこまでの話を、あんまり見ないんだよねえ・・
もうちょっと時間がかかるのかなあ・・・
実務では、マインドマップからＵＭＬという考えが、
今、勢いありますよね・・
マインド・マップとUMLを使った要求分析支援（前編）
マインド・マップの基本と応用
http://www.atmarkit.co.jp/farc/rensai/mm01/mm01a.html
実務的には、マインドマップを使って要求分析を行い、
それを、ユースケースに落としていき、
そのユースケースを元に、さらにマインドマップを使って、
アクティビティ図に発展させていくという流れが
出てくるに違いない。
要求からユースケースを出す方法は、アカデミックな世界では、
ゴール指向分析のＫＡＯＳで議論されているので、それを
そのまま持ってきてもいい・・・
ただ、これを、アカデミックな世界にもっていくのには、
無理がある。
マインドマップは、恣意性がありすぎるのだ。
なんたって、はっきりした決まりがないからね。
これが、反証可能性があるか・・・とかいう問題に引っかかってくる。
素直にもって行きにくい。
と・こ・ろ・が・・・
ここに、ちょうど手ごろな自由度を持ったものがある。
ＲＤＦ。
これは、主語－動詞－目的語という３つ組みを表現する。
目的語を主語に入れ替えると、どんどんレゴブロックのようにつなげて、
リンクできる（Ｌｉｎｋｅｄ Ｄａｔａ）
形態素解析で、なんかしようという流派に対しても、
主語、動詞、目的語の分類は受け入れられるものだし、
マインドマップの場合、線の上に描かれた言葉が、
主語、動詞、目的語のどれかにあたる
とすると、まあ、形になる。
ＲＤＦなら、検索とか加工もしやすい。
なので、業務体系をＲＤＦで表現するっていう話もありだ。
まあ、こんな感じなので、当分、実務ではマインドマップを使ったものが
先行し、アカデミックな分野では、その後を追いかけるということになるのかな
と思っている。
ソフトウェア工学ネタなら困らないので、今日も書いてみる。
そのうちアクセス減ったら、また止めるけど・・・
実はastahを使って要求から画面作成までを一気通貫（＆自動生成）する方法の論文が無料で見れる
http://blog.goo.ne.jp/xmldtp/e/c065809180323d35203281c33cf2be68
に書いた、その先・・・なんだけど、２つの方向がある
１つは、入出力項目から、ＤＢに行く方向、
もう一つは、要求文から一気に自動生成する方向。
上記の入出力項目からＤＢを生成する方法は、
佐藤正美,論理データベース論考―データ設計の方法:数学の基礎とT字形ER手法
ソフトリサーチセンター (2000)
に、確か出ていたかな・・・この本、はじめの数学は読み飛ばしていい。
あとのＴ字型ＥＲ図の作成手順からよみはじめる。
最近の佐藤氏の本は読んでいないのでわかんないけど、書いてあるのだろうか・・
ただ、ペーパーになると、はっきり書いてある論文は・・・みてないなあ・・
（ごめん、不勉強なだけかも）
実は、コンサルや実務家が本を書くのと、研究者が論文にするのには、
かなりギャップがある。
この前のastah使って・・で紹介した、小形先生、松浦先生の論文が出たのは、
２０１０年。
実務家の人が、それらしきことを言ったのは、
テクノロジックアート , C&R研究所 , 橋本 大輔, 長瀬 嘉秀,アッと驚く達人の技 UMLシステム設計実践技大全
ナツメ社(2003)
で、２００４年ごろ（本が出たのが２００３年１２月）
この本を見れば、ＵＭＬでどうすれば開発できるか、一通りわかる
（つまり、今なら１円＋送料で、ＵＭＬの開発の流れがわかる）
でもその本が出た後、日本人はヤコブソン大好きなので
（ヤコブソンも日本好きなんだよね）、ＩＣＯＮＩＸに行った。
また、実務では、ＲＵＰなんかの方法論も出たけど、
ＲＵＰは重くて、ＩＣＯＮＩＸには無駄もあって、
「UMLシステム設計実践技大全」の手法が圧倒的にわかりやすかったので、
この手法に落ち着いたのかな・・・
ただ、実務的には、論文に耐えうるものは出てなくて、
２０１０年のあの論文まで、待ったっていう感じかな・・
ここまで、数年の歳月が流れてる。
つまり、コンサルや実務家は、ラフな議論でいいので、
本が早くでる。
一方、論文、とくにフルペーパーになるのには、
ある程度厳密な議論と実証がいるので、時間がかかる。
この間、かなりギャップがある。
クラス図からＤＢ化の手法は、
現在、この時間のギャップのハザマにあるかんじかしらね。
一方、要求文から、直接プログラムを自動生成していく手法は、
研究者中心に活動してるけど、道半ば。
言語的に制限を加えたり、自然言語を構文解析したり。
ただ、構文解析の場合、形態素までに分けてしまうと、
文章の関連(係りうけ）とかが見えてこない。
さらに、複文・重文が作れちゃうと困る。
ってなってくると、係り受けが重要で、南瓜の出番なんだけど、
そこまでの話を、あんまり見ないんだよねえ・・
もうちょっと時間がかかるのかなあ・・・
実務では、マインドマップからＵＭＬという考えが、
今、勢いありますよね・・
マインド・マップとUMLを使った要求分析支援（前編）
マインド・マップの基本と応用
http://www.atmarkit.co.jp/farc/rensai/mm01/mm01a.html
実務的には、マインドマップを使って要求分析を行い、
それを、ユースケースに落としていき、
そのユースケースを元に、さらにマインドマップを使って、
アクティビティ図に発展させていくという流れが
出てくるに違いない。
要求からユースケースを出す方法は、アカデミックな世界では、
ゴール指向分析のＫＡＯＳで議論されているので、それを
そのまま持ってきてもいい・・・
ただ、これを、アカデミックな世界にもっていくのには、
無理がある。
マインドマップは、恣意性がありすぎるのだ。
なんたって、はっきりした決まりがないからね。
これが、反証可能性があるか・・・とかいう問題に引っかかってくる。
素直にもって行きにくい。
と・こ・ろ・が・・・
ここに、ちょうど手ごろな自由度を持ったものがある。
ＲＤＦ。
これは、主語－動詞－目的語という３つ組みを表現する。
目的語を主語に入れ替えると、どんどんレゴブロックのようにつなげて、
リンクできる（Ｌｉｎｋｅｄ Ｄａｔａ）
形態素解析で、なんかしようという流派に対しても、
主語、動詞、目的語の分類は受け入れられるものだし、
マインドマップの場合、線の上に描かれた言葉が、
主語、動詞、目的語のどれかにあたる
とすると、まあ、形になる。
ＲＤＦなら、検索とか加工もしやすい。
なので、業務体系をＲＤＦで表現するっていう話もありだ。
まあ、こんな感じなので、当分、実務ではマインドマップを使ったものが
先行し、アカデミックな分野では、その後を追いかけるということになるのかな
と思っている。
みんなから、無慈悲な稲妻を受けないために、
大事そうなところを、超訳＆ななめ読みしている
PressmanのSoftware Engineeringを超訳ななめ読みする
前回は、第一章のはじめだったので、
今日は、そのつづきから。
（「第一章 ソフトウェアとソフトウェア工学」つづき）
ソフトウェアは死んだのか？もしそうなら、この本は読んでいないだろう
コンピューターソフトウェアは、世界的に見て、唯一の最も重要な技術であり続けている。そして、「意図せざる結果の法則」の一番の例でもある。
５年前、誰が、ソフトウェアが、ビジネス、科学、エンジニアリングに欠くことのできない技術になると予想できたであろうか。（いや、５年前には、予想できただろう・・というツッコミは無視します：このことばは原文にない）ソフトウェアは新しい技術を創出した（例えば、遺伝子工学やナノテク）。そして既存の技術を拡張した（例えば、テレコミュニケーション）。さらに古い技術を革新的に変えた（例えば印刷業）。これらのソフトウェアは、ＰＣの変革を背景として、突き動かされたものである。
パッケージ化された（訳注：シュリンクラップ→パッケージソフトにビニールがかかっている。あのビニールをかける工程をシュリンクラップという。工場でやるのが普通だが、同人などで少ない量の場合、東急ハンズでキットが売っているらしく、それをドライヤーでほにゃほにゃすると、シュリンクされる。原文はシュリンクラップだが、パッケージ化に変えた）ソフトウェアが、近くの商店街でお客に買われたが、それが、Ｗｅｂブラウザから、ジャスト・イン・タイムで運び、オンデマンドで提供するソフト会社のサービスとして、製品が提供されるという、緩やかな進化が起きている。
ソフトウェア会社は、もっと大きくなり、より影響力を持っている。インターネットという、ソフトが動かすネットワークは、図書の検索から、ショッピング、政治談話、若い人（やそんなに若くない人の）デートの習慣までも進化させ、変えさせた。
誰も、ソフトウェアがあらゆる種類のシステムに組み込まれることを予見できなかった。交通、医療、テレコミュニケーション、軍事、産業、エンターテイメント、オフィス機器・・・リストを挙げれば、きりがない。
「意図せざる結果の法則」を受け入れるなら、予見できなかった多くの結果を挙げられる。
誰も何百万ものコンピュータープログラムが、正しく、調整されて、時間経過と共に拡張されるなんて、予見できなかった。この保守活動という負担が、新しいソフトを開発する全作業より、多くの人、多くの資源を飲み込んでいった(太字は訳者が勝手につけた）。
ソフトウェアの重要性が増大するにつれ、ソフトウェアのコミュニティも、プログラムを構築し、保守するのに、早く、速く、高くない開発技術を継続的に試みるようになった。これらの技術のいくつかは、特定のアプリケーションのドメインを狙ったもの（例えば、Ｗｅｂデザインと実装）だったり、またある技術ドメインにフォーカスしたり（例えばオブジェクト指向のシステムや、アスペクト指向プログラミング）、さらに幅広い分野のモノもある（例えばＬｉｎｕｘなどのＯＳ）。しかし、私たちはまだ、ソフトウェア技術を開発している。人々は、仕事、快適さ、安全、エンターテイメント、意思決定、まさに生活をコンピューターのソフトウェアに期待している。それは良くなる。
この本は、コンピューターソフトウェアを構築する人、つまりそれらを良くするに違いない人に使ってもらえるフレームワークを提供する。そのフレームワークは、プロセス、一連の方法論やツール群、つまり私たちがソフトウェア工学というものにまで広がっている。
このあとから、１．１章「ソフトウェアの特徴」に入っていくけど、
その前に、アジャイルを先にかいていこうと思う。
大事そうなところを、超訳＆ななめ読みしている
PressmanのSoftware Engineeringを超訳ななめ読みする
前回は、第一章のはじめだったので、
今日は、そのつづきから。
（「第一章 ソフトウェアとソフトウェア工学」つづき）
ソフトウェアは死んだのか？もしそうなら、この本は読んでいないだろう
コンピューターソフトウェアは、世界的に見て、唯一の最も重要な技術であり続けている。そして、「意図せざる結果の法則」の一番の例でもある。
５年前、誰が、ソフトウェアが、ビジネス、科学、エンジニアリングに欠くことのできない技術になると予想できたであろうか。（いや、５年前には、予想できただろう・・というツッコミは無視します：このことばは原文にない）ソフトウェアは新しい技術を創出した（例えば、遺伝子工学やナノテク）。そして既存の技術を拡張した（例えば、テレコミュニケーション）。さらに古い技術を革新的に変えた（例えば印刷業）。これらのソフトウェアは、ＰＣの変革を背景として、突き動かされたものである。
パッケージ化された（訳注：シュリンクラップ→パッケージソフトにビニールがかかっている。あのビニールをかける工程をシュリンクラップという。工場でやるのが普通だが、同人などで少ない量の場合、東急ハンズでキットが売っているらしく、それをドライヤーでほにゃほにゃすると、シュリンクされる。原文はシュリンクラップだが、パッケージ化に変えた）ソフトウェアが、近くの商店街でお客に買われたが、それが、Ｗｅｂブラウザから、ジャスト・イン・タイムで運び、オンデマンドで提供するソフト会社のサービスとして、製品が提供されるという、緩やかな進化が起きている。
ソフトウェア会社は、もっと大きくなり、より影響力を持っている。インターネットという、ソフトが動かすネットワークは、図書の検索から、ショッピング、政治談話、若い人（やそんなに若くない人の）デートの習慣までも進化させ、変えさせた。
誰も、ソフトウェアがあらゆる種類のシステムに組み込まれることを予見できなかった。交通、医療、テレコミュニケーション、軍事、産業、エンターテイメント、オフィス機器・・・リストを挙げれば、きりがない。
「意図せざる結果の法則」を受け入れるなら、予見できなかった多くの結果を挙げられる。
誰も何百万ものコンピュータープログラムが、正しく、調整されて、時間経過と共に拡張されるなんて、予見できなかった。この保守活動という負担が、新しいソフトを開発する全作業より、多くの人、多くの資源を飲み込んでいった(太字は訳者が勝手につけた）。
ソフトウェアの重要性が増大するにつれ、ソフトウェアのコミュニティも、プログラムを構築し、保守するのに、早く、速く、高くない開発技術を継続的に試みるようになった。これらの技術のいくつかは、特定のアプリケーションのドメインを狙ったもの（例えば、Ｗｅｂデザインと実装）だったり、またある技術ドメインにフォーカスしたり（例えばオブジェクト指向のシステムや、アスペクト指向プログラミング）、さらに幅広い分野のモノもある（例えばＬｉｎｕｘなどのＯＳ）。しかし、私たちはまだ、ソフトウェア技術を開発している。人々は、仕事、快適さ、安全、エンターテイメント、意思決定、まさに生活をコンピューターのソフトウェアに期待している。それは良くなる。
この本は、コンピューターソフトウェアを構築する人、つまりそれらを良くするに違いない人に使ってもらえるフレームワークを提供する。そのフレームワークは、プロセス、一連の方法論やツール群、つまり私たちがソフトウェア工学というものにまで広がっている。
このあとから、１．１章「ソフトウェアの特徴」に入っていくけど、
その前に、アジャイルを先にかいていこうと思う。
ビッグデータという、99％の事業者には効果の無い話
http://bylines.news.yahoo.co.jp/yamamotoichiro/20130328-00024117/
だけど、（以下太字は上記サイトより引用）
ローソンのCRM戦略に関する内容が界隈でバズっており、にわかに盛り上がっておりますが、あまりにも馬鹿馬鹿しいので言及しておきます。
(中略）
現実で起きていることは「あれだけのデータを活用しておきながら、たいしたことが分かっていない。あるいは発表できるレベルに達していない」という話なんですよね。なんですか、その微妙すぎるリサーチ結果は。約5,200万人の会員データを駆使して「1割の客が6割の売り上げを上げる」とか「徒歩5分以内、距離にして半径354メートルの客層にリーチする作戦だ」など、そんなもの当たり前じゃないですか。これでどうやって商品開発に繋げているんです？
ビッグデータだhadoopだ関係なく、パネル使ってサンプル調査するだけで分かる話でしょう。
あ～、山本一郎氏がおっしゃっていることはもっともだ。
そもそも、全体論を述べるなら、ビッグデータを用いないほうがいい。
テレビの視聴率は、全国民データを集めれば、正しく集計できる（理論上）けど、
実際には、極少数のサンプルしかとってないらしい。
理由は、それで足りるから・・・
それどころか、いっぱい取ってしまうと、雑音が入ってしまう。
たとえば、２０代の男性のデータを集めて、髪型を論じることはできるかもしれない。
しかし、全国民の男性のデータを集めて、髪型を論じると、おかしなことになる。
「日本では、スキンヘッドが流行っているそうです！！」
「それ、年配の人は、ハゲが多いだけですやん ＾＾；」
みたいな・・・
さっきのテレビの視聴率でいうと、ある時間にＴｗｉｔｔｅｒやＦａｃｅｂｏｏｋで、
「この番組を見てください」というと、そこだけ、視聴率が上がる可能性がある。
現状は、視聴率のサンプルになっている世帯はみんなから知らされていないし、
リサーチ会社が管理統制できているので、おかしなことは起こらない。
たしかに大数の法則があるから、大量のデータを集めると、いろんな策略お構いなしに
真実に近くなる。しかし、そこまで大量のデータをあつめると、みんなに共通している
ことしか、言えなくなるので、当たり前の結果となる
よく、ヘビーユーザーの動向を調べるが、もし、ヘビーユーザーが、
単価の安いものしか買わないと、ヘビーユーザーをいくら調べても、
安いものしか買われず、もうからなくなる。
そうではなく、企業側が買って欲しい(儲かる)商品を、買ってもらう
ために、データを使う。そのために、ビッグデータが必要になることがある。
たとえば、先ほどの視聴率の例で言うと、ＮＨＫが視聴率を上げるのに、
紅白歌合戦を解析しても、たいして大きな利益をもたらさない。
今の視聴率の３倍は理論上、無理だろう（視聴率１００％を超えるので）
それより、毎日やっているけど視聴率の少ない、ＮＨＫ高校講座の視聴率を
上げたほうが、大きく寄与する。たぶん、アノ番組、視聴率が１％もないので、
理論上は、何十倍の視聴率にすることも可能だ！
で、高校講座を考えた場合、仮に視聴率が０．１％だとすると、これは、
１０００人集めても、１人しか見ないことになるので、これじゃ、標本にならない。
まあ、最低１００人ってことになると、１０万人？
ところが、ＮＨＫの高校講座は、ＮＨＫ学園の人は必ず見る。この人たちを
しらべても、(必ず見る人なので）視聴率アップにならない。
ＮＨＫ学園の人を引くと・・・１００人集めるのに、もっともっと人を集めない
といけない。さらに、その人たちをクラスタリング分析するとなると・・・
もう、１０００万人くらいあつめないと・・・
で、その人たちが、どういう行動をとって、何を考えているか・・
というと、まず、クラスタリングして、それぞれのペルソナをつくり、行動パターン
を推測するんだけど、そのためには、テレビの番組以外の情報も必要だし、
ＮＨＫ以外で何を見ているかが必要になる。
ただ、あらかじめＮＨＫの高校講座を見ている人はわからないので、１０００万人の
いろいろなデータをあつめないといけなくなる。
これで、ビッグデータになるわけ。
ＮＨＫの紅白みたいに、多くの人が見ているデータなら、ビッグデータにしなくても
分析はできることが多い。
PONTAの場合でいうと、ある特定の売りたい商品を購入した人の分析とか、
流行っていない個店をみつけ、そのお店のお客が、
他のローソン、ローソン１００に行っているか？
何かっているか？
を調べるのであれば、ビッグデータは生きてくると思う。
ってかさあ、この前、５．２から、５．３に上げましょうとか、
いってなかったっけ？
今度は、５．４なの・・・
PHP、5.3 系のサポート終了が迫るも移行進まず
http://developers.slashdot.jp/story/13/03/26/0247229/
いってなかったっけ？
今度は、５．４なの・・・
PHP、5.3 系のサポート終了が迫るも移行進まず
http://developers.slashdot.jp/story/13/03/26/0247229/
ウィリアムのいたずら @xmldtp
アクセス
トータル
ランキング
