「警視庁犯罪抑止対策本部」をテキストマイニングしたら、なんか出てくるかも・・・

警視庁犯罪抑止対策本部
https://twitter.com/MPD_yokushi

のツイートを見てて思った
（見てない人に・・・起きている犯罪の手口のツイートが多い）

これ、テキストマイニングしたら、なんか出てくるかなあ・・
共起関係をみて（変換間違いじゃないよ）、犯行の手口の類型化とか・・
もう、だれか、やってるのかなあ・・

ベンダー各社の上流工程の開発手法（NTTデータのTERASOLUNA等）が載ってる

今月号の情報処理学会が出している、情報処理　デジタルプラクティス　Vol.4 No.2

デジタルプラクティス ＞ Vol.4 ＞ No.2
https://ipsj.ixsq.nii.ac.jp/ej/index.php?action=pages_view_main&active_action=repository_view_main_item_snippet&index_id=7034&page_no=1&list_view_num=20&sort_order=7&page_id=13&block_id=8

（以下太字は、上記の号の中の論文のタイトル）

要求工学特集なんだけど、その中に、SIベンダー各社の上流工程の開発方法が載っている

【ＮＴＴデータ】

TERASOLUNA：上流プロセスの整備・体系化の取り組み−システムの目的と要求の明確化に向けて−

はTERASOLUNA

目的と手段の断絶を解消するビジネスモデリング方法論の実践-気づきから要求を導く-

はＭＯＹＡ

【富士通】

要求工学の実践ノウハウを集大成した要件定義手法Tri-shapingの実践

は、Tri-shaping（最近は、C-NAPしてない？）

【日立】

要求開発手法HyThologyの開発と実践−REBOK実践の取り組み−

がHyThology

超上流工程における合意形成手法「Exアプローチ」

がＥｘアプローチ

【その他】
SIerではないけど、有名どころ・・・

人事・給与システム：大規模シェアード型府省共通業務情報システムの開発−ユーザ参画型の業務要求定義から−

が、電子政府の人事院の最近のほう
（人事院のシステムは、電子政府のＥＡの手法で、一回失敗している。その後、ユースケースを中心とした、まったく違った手法で成功している。上記論文は、その成功した手法のほう。ちなみに失敗したＥＡの手法は、その後、経済産業省のページからひっそりと消え、国立国会図書館の魚拓上でしか見えなくなった。ただし、地方自治体は（その失敗した）ＥＡ手法で、今もやっているので、各地方自治体のサイトで、その内容は見ることができる）

---

デジタルプラクティスは、タダでダウンロードできる
（ただし、ログインが必要なので、いっちばん上の右側にひっそりとある、新規登録を
しないといけないのかな？）

Astah*で、上流から、下流まで、トレーサビリティをもって開発する方法（４）

Astah*で、上流から、下流まで、トレーサビリティをもって開発する方法（３）
http://blog.goo.ne.jp/xmldtp/e/cb7b784d5e73df3d147ec3bc2ae1b6b0

で書いた話の続き。

View,Modelが埋まってきて、とくにViewは画面に分割できた。
のこりは、コントローラーなのだが、ここで問題がある。

今日は、そこから話をはじめる・・・

---

■コントローラーは、フレームワークに結び付いている

　コントローラーは、フレームワークに結び付いています
　たとえば、

　　strutsであれば、コントローラーは、Action「クラス」であり、
　　　Viewのイベント（メソッドに表現されている）と結び付くのは
　　　このActionクラス

　　cakephpであれば、コントローラーは、Action「メソッド」であり、
　　　Viewのイベント（メソッドに表現されている）と結び付くのは
　　　このコントローラークラスのActionメソッド

　というわけで、クラスの単位が違うわけです。
　そこで、コントローラーを決める前に、フレームワークを決める必要が
あるわけです。

---

■フレームワークの決定

　これは趣味とか、思惑とか、宗教とか、そんな感じの問題です。

　今回は、ＣａｋｅＰＨＰと決めてしまいます。

---

■コントローラークラスの決定

　そして、コントローラーグラスを具体的に決めます。

　ＣａｋｅＰＨＰだとしても、１画面１コントローラークラスにして、
作成することも可能です。
　また、もっと大きく取って、
　　　コントローラークラスは、ユースケースにすることもできるし、
　　　やる気になれば、１モデル１コントローラーにもできます
　　　　　→これをすると、bakeでの自動生成がしやすい？

　今回は
　　「１コントローラークラスは、１ユースケース」
　とします。

---

■アクションメソッドの決定

　コントローラークラスの中の、アクションメソッドですが、これは、
　Ｖｉｅｗ（でおきるイベントの）メソッドに対し、
　（呼び出される）Ａｃｔｉｏｎメソッドはあるはずです。

　ただし、次画面表示に関しては、かならずしもメソッドが必要なわけではありません。
　１アクションに対し、かならず次の画面が決まっている場合は、
　Ｖｉｅｗから呼び出されたＡｃｔｉｏｎメソッドで、次画面表示を行ってもいいわけです。

　そこで、このようにします。

　　　・まず、取り合えず、Ｖｉｅｗから呼び出されるＡｃｔｉｏｎメソッドを作ります。

　　　こんなかんじ


　　　問３画面の「課題文表示（）」は、コントローラーにありません。
　　　これは、View上で表示するだけで、コントローラーに来ないためです。

　　　集計結果表示画面の「結果表示（）」もコントローラーにありません。
　　　これは、上述の「Ｖｉｅｗから呼び出されたＡｃｔｉｏｎメソッドで、次画面表示を行」う
　　　パターンです。
　　　アンケート集計管理の集計開始メソッド内で、集計結果表示の内容をつくってしまうため、
　　　アクションメソッドが作られていません


　　・画面のＡｃｔｉｏｎから、コントローラーを呼び出し、画面を表示するという流れが
　　　滞りなく、抜けがないか確認する
　　　　→そのため、画面遷移図等を作ります。

---

　ということで、次は、画面遷移などの話にいきます。

Excelの凡ミスで、世界中の人の人生が狂わされている現実！

すげ～・・・

ここ

「ごめんなさい」では済まされない！　財政切り詰め策の根拠となった論文に誤り　欧州連合の方針に疑問
http://markethack.net/archives/51871682.html

（以下太字は上記サイトより引用）


２００９年にギリシャ問題が発覚し、それが欧州財政危機問題へと拡大した際、欧州委員会は危機を回避する政策を策定するにあたってひとつの論文を参考にしました。

それはハーバード大学のケネス・ロゴフ教授とハーバード・ケネディ・スクールのカーメン・ラインハート教授による「Growth in a Time of Debt（国家債務時代の経済成長）」という論文です。


この論文、


「国家負債が９０％を超えるとGDP成長が著しく鈍化する」


と主張されているが、


マサチューセッツ大学アマースト校の博士課程に学ぶトーマス・ハーンドンがこの論文に書かれている結果を再現しようとしたところ、ロゴフ教授とラインハート教授が主張するような、「国家負債が９０％を超えるとGDP成長が著しく鈍化する」という結果が得られませんでした。そこで彼の指導教授であるマイケル・アッシュ教授ならびにロバート・ポーリン教授とともに「結果がそうならなかった」という指摘をしました。


で、


結局、ロゴフ教授とラインハート教授がエクセルのスプレッドシートを操作する際、コーディングのミスをした為、一部のデータが演算に反映されていなかったことが判明しました。


つまり、欧州連合の方針として、ギリシャやスペインは切り詰め政策を強要されていて、
その影響は、ヨーロッパ、さらに世界中の人々が受けている。
切り詰め政策で景気が悪くなり、人生が狂わされた人も数多くいると思われるが、

その原因は、
ロゴフ教授とラインハート教授のExcelのコーディングミス
のためでした（＾＾；）
っていうお話。

・・・まじ！

「秒速で結婚」する人がいたり「世界一即戦力な男」がいたり、「砂に埋まった社長」の会社は・・・

人材豊富！？

「世界一即戦力な男」が内定した、「砂に埋まった社長」の会社Ligで、秒速で結婚下人がいるそうです。


弊社にて奇跡が起きた件。～秒速で結婚できた理由～
http://ameblo.jp/haruka-ito/entry-11512017989.html


いろんな人がいる会社のような・・・
ただ、この会社、何やっている会社か、知らなかったりする・・・（＾＾；）

Ｃ＃でExcel－（３）グラフを描く－折れ線グラフなど

まえに

Ｃ＃でExcel－（２）グラフを描いてみる
http://blog.goo.ne.jp/xmldtp/e/c1223d4427fb2dc432e3493efa13b9d5

でグラフを描いた。今回は、
　　・ダイアログボックスを使わず（コマンドラインから起動する）、
　　・折れ線グラフを
書いてみたいと思う。

---

■お題

以下のようなExcelファイル

「PHPExcelSimple1.xls」を読み込み（PHPのときと同じもの）

のように、グラフをつけて
「PHPExcelSimple3.xls」に書き出しなさい

---

■環境
Visual Studio Ｃ＃ 2010
Excel 2003(Office 2003 プロフェッショナル版の）

■手順

・１．プロジェクトを作ります
　「コンソールアプリケーション」で作ります。

・Excelの参照追加
プロジェクト→参照の追加を選択

以下のダイアログが出る

ＣＯＭタブをクリック、スクロールすると、以下のExcelのものになるので

これを選択してＯＫ

すると、ソリューションエクスプローラーをみると

Excelと（ここがちがう）
MicrosoftOfficeCore
がある。

・４．プログラミング
こんなかんじ

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            Excel.Workbooks objBooks;
            Excel.Application objApp;
            Excel._Workbook objBook;

            try
            {
                //  読み込み
                objApp = new Excel.Application();
                objBooks = objApp.Workbooks;
                objBook = objBooks.Open("C:\tmp\PHPExcelSimple1.xls");

                //  グラフを書く
                Excel.Worksheet thisWorksheet;
                thisWorksheet = objBook.ActiveSheet as Excel.Worksheet;
                Excel.ChartObjects charts =
                    (Excel.ChartObjects)thisWorksheet.ChartObjects(Type.Missing);

                // チャート作成（x = 100, y = 100, 幅500　高さ 300）
                Excel.ChartObject chartObj = charts.Add(100, 100, 500, 300);
                Excel.Chart chart = chartObj.Chart;

                // データをセット.
                Excel.Range chartRange = thisWorksheet.get_Range("A1", "D5");
                chart.SetSourceData(chartRange, Type.Missing);

		        //	折れ線グラフのチャート指定
                chart.ChartType = Excel.XlChartType.xlLineMarkers;
                chart.PlotBy = Excel.XlRowCol.xlColumns;
               


                //  ファイル保存
                objBook.SaveAs("C:\tmp\PHPExcelSimple3.xls");

                //  クローズ処理
                objBook.Close();
                objBooks.Close();
                objApp.Quit();
            }
            catch (Exception theException)
            {
                //  エラーメッセージ出力
                Console.Write(theException.ToString());
            }

        }
    }
}

・５　実行する
　デバック→デバッグ開始で

---

問題は、折れ線グラフのとき、なにを指定するか・・・
とかだが、そういう詳しいことは、マクロでグラフを描くと、
わかったりする。それについては、別の機会で・・

PressmanのSoftware Engineeringを超訳ななめ読み その７－モデリング

みんなから、無慈悲な稲妻を受けないために、
大事そうなところを、超訳＆ななめ読みしている

PressmanのSoftware Engineeringを超訳ななめ読みする

を久々に・・

いままでで、５章が終わっているので、今日は６章

---

■６章要求モデリング：シナリオ、情報、分析クラス
６．１　要求分析
　以下のタイプのモデリングが挙がっている

　　・シナリオベースモデル
　　・データモデル
　　・クラス指向モデル
　　・フロー指向モデル
　　・振る舞いモデル

６．１．１　目的と哲学の全容
　要求モデルは、「Ｗｈａｔ」に主にフォーカスを置く。「Ｈｏｗ」ではない。
　とおなじみのことが書かれた後に、３つの主な目的があるとしている
　（１）顧客の要求が何か、記述する
　（２）ソフトウェア設計を作るに当たっての基礎を確立する
　（３）ソフトウェアができた際、妥当性が確認できる要求の定義
　で、要求モデル（分析モデル）とシステム記述、設計モデルが重なるよ！
　ということを、図６．１で示している

６．１．２　分析ルール
　あ～６個載ってる。省略！

６．１．３　ドメイン分析

６．１．４　要求モデリングアプローチ

　６．３に、要求モデルと、各種の図の関係がある。

　　・シナリオベースモデル
　　　　　ユースケース
　　　　　ユーザーストーリー
　　・クラスモデル
　　　　　クラス図
　　　　　コラボレーション図
　　・フローモデル
　　　　　ＤＦＤ
　　　　　データモデル
　　・振る舞いモデル
　　　　　状態遷移図
　　　　　シーケンス図

　なるほど・・・

---

■６．２　シナリオベースモデリング

　６．２．１　準備段階のユースケースを作る
　　　カメラがインターネットとつながって・・・うん？
　　　とにかくＡＣＳ－ＤＣＶというのを例に、ユースケースを作っている

　６．２．２　準備段階のユースケースを洗練する

　６．２．３　フォーマルなユースケースを書く
　　　ユースケース記述に基づいて書く
　　　図６．４　にユースケース図を遣って書いている

---

■６．３　ユースケースを支援するＵＭＬモデル

６．３．１　アクティビティ図の開発
　スイムレーン１つ分のアクティビティ図

６．３．２　スイムレーンダイアグラム
　スイムレーンを並べて図を書く、ふつうのアクティビティ図

---

■６．４　データモデリングの概念

６．４．１　データオブジェクト

６．４．２　データの属性

Ｉｎｆｏ：データオブジェクトとオブジェクト指向のクラス
　　－　それらは、同じもの？

６．４．３　リレーションシップ

Ｉｎｆｏ：ＥＲ図

ソフトウェアツール：データモデリング
　目的
　メカニック
　代表的ツール
　　ERWin
　　ER/Studio
　　Oracle Designer
　　Visible Analyst

---

■クラスベースのモデリング

６．５．１　分析クラスの認識

６．５．２　属性の仕様化

６．５．３　操作の定義

　ここで６．９にクラス図

６．５．４　クラス-責務-コラボレータ（ＣＲＣ）モデリング
　図６．１１にＣＲＣカードの例がある

６．５．５　アソシエーションと依存

６．５．６　分析パッケージ
　パッケージの話

---

そのあと、サマリーがあって・・・という各章、同じ構成。

美人過ぎるＣＤＯ（チーフ・デジタル・オフィサー）に会える！申し込み？？

　美人過ぎるニューヨークのＣＤＯ（チーフ・デジタル・オフィサー）、レイチェルさん（２７歳）と会える！申し込み・・・らしい

NY市から1週間のNY旅行とあのレイチェルさんと会える権利のプレゼント企画
http://nyliberty.exblog.jp/20297271/

によると(以下太字は上記サイトより引用）


ここで1つ、「一度で良いから、レイチェルさんにお会いしてみたいなぁ・・・」と思っている、アメリカまたはイギリスにお住まいの皆さんにグッド・ニュースがあります。5/20-23にニューヨークで開催される「インターネット・ウィーク」（2013 Internet Week New York）にあわせて、ニューヨーク市からの超ビック・プレゼントが発表されました。

その内容は、ニューヨークまでの旅費と5/20-26まで1週間の宿泊費、「インターネット・ウィーク」のオール・アクセス・パス、IT企業ツアーやアフターパーティ等のほか、なんと、レイチェルさんとの一対一のミーティングも!!!　


申し込み先のサイトは、上記のサイトにいって、この引用部分のすぐあとを見るとわかる。

Astah*で、上流から、下流まで、トレーサビリティをもって開発する方法（３）

昨日、

Astah*で、上流から、下流まで、トレーサビリティをもって開発する方法（２）
http://blog.goo.ne.jp/xmldtp/e/5feafa838af667987ed230e9ef5688bc


で書いた話の続き。

昨日は、

（５）アクティビティ図の入出力に対する部分がＶｉｅｗとなり、
　　　クラス図（ＥＲ図に相当する）ところが、モデル（ＤＡＯ）になり
　　　アクティビティは、Ｖｉｅｗを受ける部分にあたるので、コントローラーとなる。

をやって、
・「年月日」といった、型の話は出てこなかった。
・「集約」でも「コンポジション」でもどっちでもいい
という話が残っていた。今日は、まずそれを片付ける。

---

■型とか、ブロックとかについて

　クラス図でＶｉｅｗを書いた。
　しかし、Ｖｉｅｗの一部分がまとまりのときがある。
　たとえば、
　　　Ｖｉｅｗで何箇所も出てくる、年月日のような型
　　　Ｖｉｅｗの中の項目の値として出てくる、男女のような決まった値
　　　Ｖｉｅｗの中の一部分(の繰り返し）として出てくる、受注明細のような部分
　こういったのは、部品として、まとめておく。

今回だと、問４は、男女なので、こんなふうに書ける

男女だと、ステレオタイプは本来、enumなんだろうけど、上記のモノを、
全部まとめて扱いたいので、こんなふうにしている。

受注明細は、こんなかんじ

受注と受注明細のように、部分になっているものは、線をつなぐ
（でないとわからないから）
型の場合は、クラスを切って、型のところの名前をセット
（型名でつながりはわかるから）

「商品」は、部品になるんじゃないの・・・
という至極当然な意見があると思う。
部品にしてもいい。でも、この段階でやらなくてもいい。
あとで、正規化するときにすればよい。

これらの部品(ステレオタイプparts）は、
　　モデルでは、テーブルとして
　　Viewでは、１つの部品に
なる「可能性がある」（ならないこともある）

---

■「集約」でも「コンポジション」でもどっちでもいい

　画面に分割したとき、元の画面と、分割した画面は、

「集約」でも「コンポジション」でもどっちでもいい

と書いた。その心は、上に書いた、「商品」の分割と同じ。
この段階で、コンポジションにしてしまっても、後でまとめて
考えても良い。

本来、集約とコンポジションの違いは、私の理解が正しければ、

　　集約は親子の生存の制限はない
　　コンポジションは、生存が一致

ということは、たとえば、共通画面みたいなのが出てきた場合、
コンポジションではない。他のところでつかわれるかもしれないから。

画面分割中に、この画面は、このように分割され、ここでしか使われない
と判っていれば、コンポジションにできるかもしれないが、
そうでない場合、集約でかまわない。
全部画面を書き出してから考えれば良いし、そもそも、コンポジションか
集約かで、開発が変わることもない。
なので、集約で書いてかまわない。この前の例もそうしている。

---

ということで、疑問点は書いた。
次回は、


（４）その後、ＭＶＣアーキテクチャを採用したとすると、
　　　なんかのフレームワークを決めて、

について

ソーシャルゲーム、開発会社の黄昏

Klabの話を中心とした、ソーシャルゲームの採算悪化の問題。
開発スピードが遅れ・・・というのは、既視感が・・・
ゲーム業界と同じ構造？

ソーシャルゲーム、開発会社の黄昏
http://zasshi.news.yahoo.co.jp/article?a=20130417-00013690-toyo-bus_all

「今出しょう子」が、「エイっ子」に載っているそうです。

あ・・・・

ここのブログ

Windows XPのサポートが終わったら、Microsoftも終わるんじゃないだろうか【連載:村上福之】
http://engineer.typemag.jp/article/fukuyuki-microsoft

(以下太字は、上記サイトより引用）
は、いろいろと意見があると思うけど、
（私も反対意見はあるが）
一番共感しそうなのは。。。

外部と組んだキャンペーンでは萌えキャラも作ったのですが、やっつけ過ぎなので、一部で、いまいち萌えなくて話題になっているようです。

Windowsストアアプリ選手権のキャラ「今出しょう子」がやっつけすぎると話題


だと思います。
そのページ

Windowsストアアプリ選手権のキャラ「今出しょう子」がやっつけすぎると話題
http://matome.naver.jp/odai/2136548553359418201

を見ると・・・

もう、ネーミング「今でしょう！子」っていうところから、やっつけすぎですが、
ポスターが

ですよ（上記サイトより引用）
(Windows 8＝)エイっとつくろう・・・
だそうです・・・

「大学入試にTOEFLを」に、大学情報系の高度ＩＣＴ人材育成の失敗を感じる・・・

最近、「大学入試にTOEFLを」という話が話題のようだ。
その中でも、話題沸騰？の・・・

教育再生実行本部の「提言」全文入手
http://blogs.yahoo.co.jp/gibson_erich_man/32702333.html

(以下太字は上記サイトより引用）
を見ていて思ったことをちょっと書いてみたい。

---

今回の提言は

「結果の平等主義から脱却し、トップを伸ばす戦略的人材育成」

だそうな。あ～、トップを伸ばす・・・懐かしい響きですね。


コンピューター業界にも、ありました。
経団連の

「産学官連携による高度な情報通信人材の育成強化に向けて」
http://www.keidanren.or.jp/japanese/policy/2005/039/honbun.pdf

実はこれ、上記のＰＤＦの１１ページはじめを見てもらうと判るけど
（以下斜体は上記サイトより引用）

将来的には、このようなトップレベル層の高度ＩＣＴ人材は新卒者として毎年3,000人程度必要になる。
このような人材を早期に育成するためには、従来の大学・大学院にはない、高度なＩＴの専門教育や、ソフトウェアの開発手法等の研究開発を行なう、実践性を備えた世界レベルの先進的ＩＴ拠点(先進的実践教育拠点)を、意欲を持った大学・大学院から選抜、もしくは新設し、産学官連携による重点的な資源投入の下、トップレベルの高度ＩＣＴ人材を育成する必要がある


というので始まった、高度ＩＣＴ人材、つまり、ＩＣＴの「トップを伸ばす戦略的人材育成」だった
わけだが、結果はどうなったか・・・

---

大学でＰＢＬを行ったりすることは多くなった。
基本情報とかを取る人は増えたかもしれない。

でも、この活動で、オープンソースで活躍した人が増えた？
ここ数年、新入社員のプログラム能力やシステム開発力が上がっているだろうか？
将来的に、トップを担う人材が、どんどん採用できるようになったであろうか？


結局２０１１年の経団連の提言

今後の日本を支える高度ICT人材の育成に向けて
〜改めて産学官連携の強化を求める〜
http://www.keidanren.or.jp/policy/2011/096honbun.html

では、（赤字は上記サイトより引用）


卒業時点で、システム開発の経験を求める声は多くない。


そして、

経団連のアンケートによると、今後、企業の中核を担う高度ICT人材に求める資質として、リーダーシップを発揮し最後までやり遂げる能力、自社や業界を俯瞰できる能力、課題・リスク等を分析し対策を立案・実施できる能力といった、高い能力が求められている。製品開発や自社のビジネスに係る情報のデジタル化やプロセスの管理に留まらず、様々な情報、機器、ヒトの融合による新しい社会の創造に向け、ICTを利活用した変革を牽引していくリーダー人材が望まれている。


それって、プログラム開発したり、システム設計したりでは、養えない力でないかい？

英語も、こんな風になる可能性が大きいと思う。

---

トップに必要なのは、語学力やシステム開発力も、さることながら、


リーダーシップを発揮し最後までやり遂げる能力、自社や業界を俯瞰できる能力、課題・リスク等を分析し対策を立案・実施できる能力といった、高い能力


なのですよ。それに資する能力というと、

英語だと
・リーダーシップを発揮し最後までやり遂げるために必要な、コミュニケーション能力

だし、

ＩＣＴだと
・リーダーシップを発揮し最後までやり遂げるために必要な、システム開発能力

となる。ところが、この力は、いままでも養っていないし、今も養っていない。

---

まず、ＩＣＴの世界から話そう。
２００６年当時、そして今でも・・・以下の３つの問題があった

・そもそも、システム開発手法が固まっていなかった
・そのような状態では、先生が適切な教育をしているかどうかわからない
・ということで、明確なテストの合否に大学が走っていった。

以下、順繰りに見ていく。

---

＜＜そもそも、システム開発手法が固まっていなかった＞＞

　システムは、この手順でできる！というのは、１９９５年ころには固まっていて、情報処理試験の９６年版の教科書？テキスト？には、この手法が載っている。これは構造化設計で書いてある。

　しかし、オブジェクト指向で一貫性を持ったものが出てき始めたのが２００４年ごろから。
　そのころかな？に出てきたＩＣＯＮＩＸで、一端の完成をみた・・・
　・・・が、この方法では、現在の開発実務が、できないのだ・・・

　ＩＣＯＮＩＸでは、画面分割の話とかは出てこないし、コントローラーの創り方は一通り（現場では、採用するフレームワークによって変わる）だったりする。このほか、いくつか実務的に問題がある。

　いまだに、全工程を、全部矛盾なく見せるというのは、各企業のフレームワークではあっても、オープンソースやＡｓｔａｈを使っては見たことがない。

　だから「Astah*で、上流から、下流まで、トレーサビリティをもって開発する方法」というシリーズをやっているわけだ。

---

＜＜そのような状態では、先生が適切な教育をしているかどうかわからない＞＞

　そこで、現場の先生は、現在の全工程を開発したのではない人、

　つまり、
　　・賢い大学を出て
　　・かなり昔に現場の経験を持ち
　　・今はマネージャー、研究員、もっと偉い人が
　　・昔の開発手法に基づいて
　教えているという状況になった。

　その結果、構造化手法に基づいた教育
　　ＤＦＤ書きましょうね
　　ＥＲ図書いてね！
　という方法を教えた後で・・・

　じゃ、
　　Javaで開発してみましょう！
　　ＰＨＰで開発してみましょう！！

・・・どうやって？？
・・お前（＝先生）がＤＦＤから開発して見ろよ！（－＿－；）
という結果になった。

　その結果、授業とＰＢＬが切り離されるか、
　ＰＢＬでは要求までとか、もしくは、画面設計書を作って実装
・・・という話になってきた。

---

＜＜ということで、明確なテストの合否に大学が走っていった＞＞

　はっきり言って、ばんばんモノが作れるなら、情報処理試験受けなくたって、アピールできる

「即戦力になる男－オレのGitHubをみてくれ（＾＾）ｖ」
　でＵＲＬだけ書いておけば、そのものを動かしてみれば、能力はわかる。

でも、そこまで即戦力になる男（女）は、大学ではつくれない。
あんまり、ＤＦＤやＩＤＥＦ０書いて、オープンソースの開発は、
していないと思うぞ（ＥＲ図は、わからんが・・・）

　そこで、大学は、情報処理試験に走った。

　　　ＩＴパスポート受からせよう、
　　　基本情報を受からせよう

　・・と・・・
　でも、それで、
「リーダーシップを発揮し最後までやり遂げるために必要な、システム開発能力」
が身に付くかは、かなり疑問なのだが・・・

---

英語も同じ道をたどっているようだ。

幸いにも英語は、
＜＜そもそも、システム開発手法が固まっていなかった＞＞
のレベルである

・「英語の会話のための文法」は固まっている

　まず、大西泰斗先生の、一億人の英文法とかに書かれている内容でいいだろう。

---

しかし、その次の段階

＜＜そのような状態では、先生が適切な教育をしているかどうかわからない＞＞

は、はなはだ疑問だ。
英語の先生が、本当に英語を話せるのなら、

・日本の伝統や文化など、日本人として必要な教養を身につけ、国際的に発信できる力を育成

なんて簡単だ。大学生に、観光地に生かせて、英語でガイドさせればいい。
ワキで先生が見ていて、もし、学生がおかしなこといったら、即座に訂正すれば
いいだけの話だ。果たして、できるか・・・


・小・中・高等学校における英語教育を抜本的に改革・強化、その一環として学校教育において英語に触れる時間を格段に増加（土曜日の活用、イングリシュ・キャンプ、タブレットPC等の活用）

なんてのも簡単。
そもそも、タブレットＰＣを持っていても、英語に触れる時間は、増えない。
タブレットＰＣで勉強するやつは、今、カセットテープでも勉強する。

強制的に英語を聞かせるなら、給食の時間、校内放送を英語でしゃべればいい。
毎日３０分は、必ず英語を聞く羽目になる。

で、英語の先生が、３０分間、ぶっ続けで英語をしゃべれるか、ＤＪできるか・・・

でも、逆に、通訳・ガイドの人や、Ｒａｄｉｏ　Ｊａｐａｎの人が、
大学や高校に行って、英語の授業をする機会は、すくないわけだ・・・

---

だから、結局

＜＜ということで、明確なテストの合否に大学が走っていった＞＞

となり、ＴＯＥＩＣ，ＴＯＥＦＬに走っていこうとしているわけだ。

本当に英語ができるなら、簡単だ。

エントリーシートに

「私は英語が流暢にしゃべれます。嘘だと思ったら、面接時に英語で質問してください」

と書けばいいだけのことだ。採用する企業は、英語でしゃべってくるだろう。
それに、答えればよい。

その自信がないから、テストの点でごまかしているんだろう・・・

---

というわけで、現状の「高度ＩＣＴ人材育成」状況をみると、英語で、どういうことになるかは・・・
・・・想像がついたりしますね・・

Astah*で、上流から、下流まで、トレーサビリティをもって開発する方法（２）

昨日、

Astah*で、上流から、下流まで、トレーサビリティをもって開発する方法（１）
http://blog.goo.ne.jp/xmldtp/e/ca9cc98062afa09603680042d6dc8f86

で書いた話の続きなんだけど、今日は大事なところなので、
進捗をゆっくり、その代わり、丁寧に話す。

---

昨日、


（１）ユースケースに対して、そのアクティビティを書いて、
　　　要求を明示するよねえ
　　　　→ユースケース図、アクティビティ図

（２）そのアクティビティに対し、入出力を明示し
　　　（ここが入出力設計、ＵＩ）


をやった。実は、（３）、（４）を飛ばして


（５）アクティビティ図の入出力に対する部分がＶｉｅｗとなり、
　　　クラス図（ＥＲ図に相当する）ところが、モデル（ＤＡＯ）になり
　　　アクティビティは、Ｖｉｅｗを受ける部分にあたるので、コントローラーとなる。
　　　　→コントローラーが
　　　　　　　クラスとなるか(Struts,Actionクラス）
　　　　　　　メソッドとなるか(CakePHP,Zendなど）
　　　　　は、フレームワークやアーキテクチャによる
　　　これで、アーキテクチャに基づいたクラス、メソッド割がきまる。

の途中までをやると、やりやすい（理由は（４）を説明するときに言う）

ので、今日は（５）の途中まで

---

■Viewのクラスを作る

昨日、アクティビティ図を作った。
そのとき、オブジェクトノードを入れた。
そのオブジェクトノードをクラス図に描く。

画面はステレオタイプをＶｉｅｗとし、
データ部分（ＤＢのテーブルとか）は、ステレオタイプをＭｏｄｅｌとしよう。

そうすると、まず、こんな形に書ける。

---

■Viewのデータを入れる

次に、入出力するデータを、とりあえず、全部入れる。

アンケート画面は、問１～問５まであった
　なので、こんなカタチ


集計結果表示画面は、
　問１～問４まで：円グラフ
　問５：棒グラフ
　問２、問３については、思う、思わないをクロス集計
　（きのうの、間違えていました。問２と問３のクロス集計です）

ここで、サーバー側でグラフをビットマップで作り、表示する手もあるけど、
今回は、そうではなく、クライアント側に数値を送り、それをＧＵＩで組み立てるとする。
そうすると、必要な数字は

問１を円グラフにするには、
　　問１Ａの人数、問１Ｂの人数がわかればできる

問２を円グラフにするには
　　問２Ａの人数、問２Ｂの人数がわかればできる
　　(総数は、問１Ａの数と一致するはず、しなければ無回答）

問３を円グラフにするには
　　問３Ａの人数、問３Ｂの人数がわかればできる
　　(総数は、問１Ａの数と一致するはず、しなければ無回答）

問４を円グラフにするには
　　問４Ａの人数、問４Ｂの人数、問４Ｃの人数がわかればできる
　　(総数は、問１Ａ＋Ｂの数と一致するはず、しなければ無回答）

問５を棒グラフにするには
　　問５Ａ、Ｂ，Ｃ，Ｄ，Ｅ，Ｆ．Ｇ．Ｈの各人数がわかればできる
　　(総数は、問１Ａ＋Ｂの数と一致するはず、しなければ無回答）

問２、問３のクロス集計を作るには、
　　（１）問２Ａかつ問３Ａ
　　（２）問２Ａかつ問３Ｂ
　　（３）問２Ｂかつ問３Ａ
　　（４）問２Ｂかつ問３Ｂ
の人が判ればできる。
　そして、（１）～（４）がわかれば、
　問２の円グラフ、問３で円グラフの人も計算でもとまるのでいらない。

まとめると、これだけの値がいる

　　・問１Ａの人数、問１Ｂの人数
　　・問２Ａかつ問３Ａ、問２Ａかつ問３Ｂ、問２Ｂかつ問３Ａ、問２Ｂかつ問３Ｂ
　　・問４Ａの人数、問４Ｂの人数、問４Ｃの人数
　　・問５Ａ、Ｂ，Ｃ，Ｄ，Ｅ，Ｆ．Ｇ．Ｈの人数

ただし、それぞれ持っていると、大変なので、配列にしてもっている

　　問１[0]は、問１Ａの人数、問１[1]は、Ｂの人数
　　問２３[0]は問２Ａかつ問３Ａ、問２３[1]は問２Ａかつ問３Ｂ・・・

で、こんなかんじになる

今回、送信完了と、集計画面では何も送らないので
属性は入れない
（一般には、集計画面で、表示したいアンケートを選んだりするが、
　今回は１種類しかアンケートがないので）

ということで、こんなかんじ。

---

■Ｖｉｅｗにメソッドを追加する

　Viewにメソッドを追加する。
　メソッドは、アクションを起こすところ
　　　＝結果として、イベントを起こすところ
　　　＝多くは、ボタンをおしたり（場合によってはタイマーもありだけど）

となる。

　ということは、アクティビティ図で、画面から、システムに行くところは、必ず
メソッドになる。そして、これは、ボタンをおしたときなどのアクションに結び付く
（実装上、メソッドとしてJavascriptの関数で書くか、FormタグのSubmitボタンに
　なるかは、この時点では決めなくて良い）

　今回は、あとあとの若干の理由から、「初期表示」も入れる

　また、結果表示画面は、初期表示より、結果表示のほうがいいので、そうした
　（ここで、メソッド名は、正直、どうでもよい。かっちょ良いのにしてくれ）

　こんなかんじになる。

---

■画面分割

ここで、１画面で表示しきれない、表示しないほうがいい場合は、画面分割する。

集計結果表示画面は、いいとして、アンケート画面は、このままだと困る。

　　問１で、「いいえ」と答えた人は、問４に飛ばないといけない。
　　問２と問３を同時にだしてしまうと、問２に答える前に
　　　　日本の「卵かけ御飯」が「絶対に危険な食べ物」に選ばれる…中国
　　　　http://blog.livedoor.jp/dqnplus/archives/1758248.html
　　　を見られてしまう可能性がある→その場合、問２の意味なし
　　　問２と問３は分離しないといけない。そして、後に戻れないようにする。

結果として、こういう画面割りにしないといけない

　　問１
　　問２
　　問３
　　問４・５（４と５は一緒の画面でいい）

そこで、Ｖｉｅｗの画面を分割する。
分割は（かっこ内は、問１画面の例）、

　　・分割した画面のクラスを作る（問１画面クラス）
　　・分割した画面で表示（入力）する項目をつける（属性問１を追加）
　　・もとの画面（アンケート画面）から、
　　　　分割した画面の属性を削除（アンケート画面の属性問１を削除）
　　　　分割した画面を集約か、コンポジションかにして、線を結ぶ
　　・分割した画面（問１画面クラス）にメソッドを追加する
　　　　→その画面で起こすアクション

この結果、
　　・もとの画面の属性が全てなくなれば（今回はそのケース）
　　　　その画面は抽象的にまとめたもので、実装の必要はない
　　　　このとき、元の画面（アンケート画面）のメソッドは、
　　　　集約した＝分割した画面のメソッドのどこかに対応する
　　　　はず（アンケート画面の回答実行＝問４・５の回答実行）

　　１個でも属性が残れば、
　　　　その画面は必要になる

これらの処理をして、必要となった画面を、
appview（でもdispでもなんでもいい、viewと区別する）という
ステレオタイプに変えておく。あとで判りやすくするため

結果、こうなる

---

今回は「受注明細」のような画面のかたまりや、
「年月日」といった、型の話は出てこなかった。
その操作は、次回、はなそう。

それと、「集約」でも「コンポジション」でもどっちでもいい
と書いたけど、実は、分けられる（その上で、今回は集約を使っている）
その理由も書くかも？

さらに、その後で、コントローラーなんだけど、コントローラーに行く前に、

（４）その後、ＭＶＣアーキテクチャを採用したとすると、
　　　なんかのフレームワークを決めて、

を説明する。ここで、「初期画面」を入れた謎などが、解ける
んだけど・・・ここまではいかないかな？

グーグルに差し止め命令 検索予測表示（サジェスト機能）めぐり

このニュースなんだけど、サジェスト機能全てに対してなのか、
この名誉が傷つけられたという人に関する表示だけなのか？
サジェスト機能全てだとしたら、大問題の気が・・・
さすがに、そうじゃないよね・・



グーグルに差し止め命令　検索予測表示めぐり　東京地裁初判断
http://headlines.yahoo.co.jp/hl?a=20130415-00000585-san-soci

Astah*で、上流から、下流まで、トレーサビリティをもって開発する方法（１）

こんなような話は、何回も書いているけど、
最近、ソフトウェア工学ネタで、見てくれる人が多くなった。
なので、もしかすると、見てない人がいるかもしれないので、
また、取り上げてみる。

---

■全体の流れと、今日の説明範囲

そもそもＵＭＬだと、「詳細設計書」は、書かなくないか？
http://blog.goo.ne.jp/xmldtp/e/147b230c186e8b5a3d5092cb0c50ecf9

に書いた。
(以下太字が書いたところ。なお、今回は、番号を振っている）

いい、いくよ！付いてきてね！！

（１）ユースケースに対して、そのアクティビティを書いて、
　　　要求を明示するよねえ
　　　　→ユースケース図、アクティビティ図

（２）そのアクティビティに対し、入出力を明示し
　　　（ここが入出力設計、ＵＩ）

（３）その入出力を元に（正規化とか）、クラスをつくるよねえ
　　　→クラス図（ＥＲ図に相当する）

（４）その後、ＭＶＣアーキテクチャを採用したとすると、
　　　なんかのフレームワークを決めて、

（５）アクティビティ図の入出力に対する部分がＶｉｅｗとなり、
　　　クラス図（ＥＲ図に相当する）ところが、モデル（ＤＡＯ）になり
　　　アクティビティは、Ｖｉｅｗを受ける部分にあたるので、コントローラーとなる。
　　　　→コントローラーが
　　　　　　　クラスとなるか(Struts,Actionクラス）
　　　　　　　メソッドとなるか(CakePHP,Zendなど）
　　　　　は、フレームワークやアーキテクチャによる
　　　これで、アーキテクチャに基づいたクラス、メソッド割がきまる。

（６）そして、クラスから、何を呼び出すかという、呼び出し関係と
　　　メッセージ（引数）を、シーケンス図に描き、

（７）状態遷移は、遷移図（ステートマシン図）に書ける


これを、Astahでやると、どうなるかについて書く。

また、詳細設計に相当するところはどこに書いて、
どの後どうするかについても、書いてみたい・・・

が、長くなるので今日は、（１）、（２）くらいまで

---

■御題。

　アンケートサイトを作り、集計するとする。
　アンケートの内容は、以下のとおり

・緊急アンケート ・問１ 　あなたは、卵かけご飯を食べたことがありますか 　　　Ａ：ある 　　　Ｂ：ない　→　問４へ、進んでください ・問２ 　あなたは、卵かけご飯は、危険な食べ物だと思いますか？ 　　　Ａ：思う 　　　Ｂ：思わない ・問３ 　　以下の記事を読んでください 日本の「卵かけ御飯」が「絶対に危険な食べ物」に選ばれる…中国 http://blog.livedoor.jp/dqnplus/archives/1758248.html 　あなたは、卵かけご飯は、危険な食べ物だと思いますか？ 　　　Ａ：思う 　　　Ｂ：思わない ・問４　あなたの性別について答えてください 　　　Ａ：男 　　　Ｂ：女 　　　Ｃ：その他 ・問５　あなたの年齢層について答えてください 　　　Ａ：１０歳未満 　　　Ｂ：１０代 　　　Ｃ：２０代 　　　Ｄ：３０代 　　　Ｅ：４０代 　　　Ｆ：５０代 　　　Ｇ：６０代 　　　Ｈ：７０歳以上

結果は、以下のように表示する

問１～問４まで：円グラフ
問５：棒グラフ

さらに、問３、問４については、思う、思わないをクロス集計

---

■まず、このシステムでしたいことと、それに関する人物
　(ステークホルダー）をユースケースで書く

　このシステム（アンケート）は、アンケートに回答してもらって、
集計する。当然回答する人と、集計する人がいる。
それを、ユースケースに書く。

なかんじ

---

■そのユースケースごとに、アクティビティを書く

　ユースケースは、２つ上がった
　　　ユースケース回答、
　　　ユースケース集計

　このユースケースごとに、ステークホルダーである登場人物が、どんな手順で
なにをするかを、アクティビティ図に描く。
　ステークホルダー（集計する人、回答する人）は、それぞれ、レーンになる。
　また、後作業のため、システムも入れておこう。
　こんなかんじ。

＜＜アンケート回答＞＞


＜＜アンケート集計＞＞

---

■そのアクティビティ図に入出力画面とかを入れる

　アクティビティ図に入出力画面やＤＢのデータ、帳票などを入れる。
　入れ方だが、

　　　　ステークホルダーから、システムにいくには、
　　　　　　何らかのイベントを起こすはずである＝ボタンなど
　　　　　　多くの場合、データを保存する

　　　　システムからステークホルダーに行くときは、
　　　　　　画面表示、帳票表示など、何らかのデバイスへの出力をするのが普通
　　　　　　出力するため、データを入力することが多い

　　これをもとに、オブジェクトノードを追加する。

＜＜アンケート回答＞＞


＜＜アンケート集計＞＞

---

■次回は・・・

　このオブジェクトノードをクラスにしていく。