Quantcast
Channel: ウィリアムのいたずらの、まちあるき、たべあるき
Viewing all 7292 articles
Browse latest View live

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


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

$
0
0
昨日、

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

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



昨日、


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

(2)そのアクティビティに対し、入出力を明示し
   (ここが入出力設計、UI)


をやった。実は、(3)、(4)を飛ばして


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

の途中までをやると、やりやすい(理由は(4)を説明するときに言う)

ので、今日は(5)の途中まで



■Viewのクラスを作る

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

画面はステレオタイプをViewとし、
データ部分(DBのテーブルとか)は、ステレオタイプをModelとしよう。

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



■Viewのデータを入れる

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

アンケート画面は、問1〜問5まであった
 なので、こんなカタチ


集計結果表示画面は、
 問1〜問4まで:円グラフ
 問5:棒グラフ
 問2、問3については、思う、思わないをクロス集計
 (きのうの、間違えていました。問2と問3のクロス集計です)

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

問1を円グラフにするには、
  問1Aの人数、問1Bの人数がわかればできる

問2を円グラフにするには
  問2Aの人数、問2Bの人数がわかればできる
  (総数は、問1Aの数と一致するはず、しなければ無回答)

問3を円グラフにするには
  問3Aの人数、問3Bの人数がわかればできる
  (総数は、問1Aの数と一致するはず、しなければ無回答)

問4を円グラフにするには
  問4Aの人数、問4Bの人数、問4Cの人数がわかればできる
  (総数は、問1A+Bの数と一致するはず、しなければ無回答)

問5を棒グラフにするには
  問5A、B,C,D,E,F.G.Hの各人数がわかればできる
  (総数は、問1A+Bの数と一致するはず、しなければ無回答)

問2、問3のクロス集計を作るには、
  (1)問2Aかつ問3A
  (2)問2Aかつ問3B
  (3)問2Bかつ問3A
  (4)問2Bかつ問3B
の人が判ればできる。
 そして、(1)〜(4)がわかれば、
 問2の円グラフ、問3で円グラフの人も計算でもとまるのでいらない。

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

  ・問1Aの人数、問1Bの人数
  ・問2Aかつ問3A、問2Aかつ問3B、問2Bかつ問3A、問2Bかつ問3B
  ・問4Aの人数、問4Bの人数、問4Cの人数
  ・問5A、B,C,D,E,F.G.Hの人数

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

  問1[0]は、問1Aの人数、問1[1]は、Bの人数
  問23[0]は問2Aかつ問3A、問23[1]は問2Aかつ問3B・・・

で、こんなかんじになる

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

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



■Viewにメソッドを追加する

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

となる。

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

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

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

 こんなかんじになる。




■画面分割

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

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

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

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

  問1
  問2
  問3
  問4・5(4と5は一緒の画面でいい)

そこで、Viewの画面を分割する。
分割は(かっこ内は、問1画面の例)、

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

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

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

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

結果、こうなる




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

それと、「集約」でも「コンポジット」でもどっちでもいい
と書いたけど、実は、分けられる(その上で、今回は集約を使っている)
その理由も書くかも?

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

(4)その後、MVCアーキテクチャを採用したとすると、
   なんかのフレームワークを決めて、

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

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

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

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

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



今回の提言は

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

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


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

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

実はこれ、上記のPDFの11ページはじめを見てもらうと判るけど
(以下斜体は上記サイトより引用)

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


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



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

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


結局2011年の経団連の提言

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

では、(赤字は上記サイトより引用)


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


そして、

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


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

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



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


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


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

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

だし、

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

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



まず、ICTの世界から話そう。
2006年当時、そして今でも・・・以下の3つの問題があった

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

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



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

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

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

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

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

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




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

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

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

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

 じゃ、
  Javaで開発してみましょう!
  PHPで開発してみましょう!!

・・・どうやって??
・・お前(=先生)がDFDから開発して見ろよ!(−_−;)
という結果になった。

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



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

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

「即戦力になる男−オレのGitHubをみてくれ(^^)v」
 でURLだけ書いておけば、そのものを動かしてみれば、能力はわかる。

でも、そこまで即戦力になる男(女)は、大学ではつくれない。
あんまり、DFDやIDEF0書いて、オープンソースの開発は、
していないと思うぞ(ER図は、わからんが・・・)

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

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

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



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

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

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

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



しかし、その次の段階

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

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

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

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


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

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

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

で、英語の先生が、30分間、ぶっ続けで英語をしゃべれるか、DJできるか・・・

でも、逆に、通訳・ガイドの人や、Radio Japanの人が、
大学や高校に行って、英語の授業をする機会は、すくないわけだ・・・




だから、結局

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

となり、TOEIC,TOEFLに走っていこうとしているわけだ。

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

エントリーシートに

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

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

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



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

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

$
0
0
あ・・・・

ここのブログ

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

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

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

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


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

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

を見ると・・・

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

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

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

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

$
0
0
昨日、

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


で書いた話の続き。

昨日は、

(5)アクティビティ図の入出力に対する部分がViewとなり、
   クラス図(ER図に相当する)ところが、モデル(DAO)になり
   アクティビティは、Viewを受ける部分にあたるので、コントローラーとなる。

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



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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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



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


(4)その後、MVCアーキテクチャを採用したとすると、
   なんかのフレームワークを決めて、

について

美人過ぎるCDO(チーフ・デジタル・オフィサー)に会える!申し込み??

$
0
0
 美人過ぎるニューヨークのCDO(チーフ・デジタル・オフィサー)、レイチェルさん(27歳)と会える!申し込み・・・らしい

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

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


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

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


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

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

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

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

を久々に・・

いままでで、5章が終わっているので、今日は6章



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

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

6.1.1 目的と哲学の全容
 要求モデルは、「What」に主にフォーカスを置く。「How」ではない。
 とおなじみのことが書かれた後に、3つの主な目的があるとしている
 (1)顧客の要求が何か、記述する
 (2)ソフトウェア設計を作るに当たっての基礎を確立する
 (3)ソフトウェアができた際、妥当性が確認できる要求の定義
 で、要求モデル(分析モデル)とシステム記述、設計モデルが重なるよ!
 ということを、図6.1で示している

6.1.2 分析ルール
 あ〜6個載ってる。省略!

6.1.3 ドメイン分析

6.1.4 要求モデリングアプローチ

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

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

 なるほど・・・



■6.2 シナリオベースモデリング

 6.2.1 準備段階のユースケースを作る
   カメラがインターネットとつながって・・・うん?
   とにかくACS−DCVというのを例に、ユースケースを作っている

 6.2.2 準備段階のユースケースを洗練する

 6.2.3 フォーマルなユースケースを書く
   ユースケース記述に基づいて書く
   図6.4 にユースケース図を遣って書いている



■6.3 ユースケースを支援するUMLモデル

6.3.1 アクティビティ図の開発
 スイムレーン1つ分のアクティビティ図

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



■6.4 データモデリングの概念

6.4.1 データオブジェクト

6.4.2 データの属性

Info:データオブジェクトとオブジェクト指向のクラス
  − それらは、同じもの?

6.4.3 リレーションシップ

Info:ER図

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



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

6.5.1 分析クラスの認識

6.5.2 属性の仕様化

6.5.3 操作の定義

 ここで6.9にクラス図

6.5.4 クラス-責務-コラボレータ(CRC)モデリング
 図6.11にCRCカードの例がある

6.5.5 アソシエーションと依存

6.5.6 分析パッケージ
 パッケージの話



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

C#でExcel−(3)グラフを描く−折れ線グラフなど

$
0
0
まえに

C#でExcel−(2)グラフを描いてみる
http://blog.goo.ne.jp/xmldtp/e/c1223d4427fb2dc432e3493efa13b9d5

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




■お題

以下のようなExcelファイル

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

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


■環境
Visual Studio C# 2010
Excel 2003(Office 2003 プロフェッショナル版の)

■手順

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

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

以下のダイアログが出る

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

これを選択してOK

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

Excelと(ここがちがう)
MicrosoftOfficeCore
がある。

・4.プログラミング
こんなかんじ
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()); } } } }

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



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

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

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

$
0
0
すげ〜・・・

ここ

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

(以下太字は上記サイトより引用)


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

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


この論文、


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


と主張されているが、


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


で、


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


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

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

・・・まじ!

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

$
0
0


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

で書いた話の続き。

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

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



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

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

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

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

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



■フレームワークの決定

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

 今回は、CakePHPと決めてしまいます。



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

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

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

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



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

 コントローラークラスの中の、アクションメソッドですが、これは、
 View(でおきるイベントの)メソッドに対し、
 (呼び出される)Actionメソッドはあるはずです。

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

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

   ・まず、取り合えず、Viewから呼び出されるActionメソッドを作ります。

   こんなかんじ


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

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


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



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


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

$
0
0
今月号の情報処理学会が出している、情報処理 デジタルプラクティス 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ベンダー各社の上流工程の開発方法が載っている

【NTTデータ】

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

はTERASOLUNA

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

はMOYA

【富士通】

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

は、Tri-shaping(最近は、C-NAPしてない?)

【日立】

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

がHyThology

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

がExアプローチ

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

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

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



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

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

$
0
0

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

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

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

ディペンダビリティを見える化するD-Caseの話を聞いてきた

$
0
0
ディペンダビリティを見える化する手法?ツールにD-Caseってのがある。
今日、第3回D-Case実証評価研究会のはじめのほうを、慶応の日吉で聞いてきたので、
そのメモメモ

第一弾は、
「D-Case、DEOSへの期待 〜品質説明力の強化に向けて〜」
  IPA SEC 田丸氏



・組み込みソフトウェア開発の課題
 1位:設計品質が2006年〜2012年までトップ
 それ以下は、景気によって変わる(新製品/経費削減)

・製品出荷後の不具合発生製品率の推移
 リーマンショック前
   40数パーセントがないと答えた
     →品質改善された
 その後
   なしと答えた人半減
     →品質悪くなったまま、改善しない
 理由
   開発費削減→自分たちで開発して
   ベテラン技術者が定年、新入社員増えてきた

・製品出荷後に発生した不具合の原因
  3分の1はソフトだが、
  他製品との接続など、
    マーケットに出て、使用環境における不具合
    が増えてきた

・組み込みシステムの変遷
  バブル前:
    半導体中心(特注のLSI):電子立国日本
  バブル崩壊:
    組み込み用マイコン
     価値の源泉がソフトウェアへ
  98年
    OS、ミドルウェア(I-TRON)
  ITバブル崩壊
    プラットホーム化(BREW、Android)
  リーマンショック
    つながる時代?
 東芝とルネサスが半導体ベスト10に残っている

 組み込みXクラウドXモバイル

・「組み込みXクラウドXモバイル」の役割分担
   機械系−組み込み系(センサー入力など)
   人間系−モバイル系(ヒューマンインターフェース/利用状況)
   クラウド系−非リアルタイム処理、データ管理
 システム全体の信頼性は?

・スマホで車を操作
  車の信頼性とスマホの信頼性は違う

・組み込み、クラウド、モバイルの特性の違い
  結構、違う(開発の方向性とか)
  なんか、一工夫しないと、できそうにない

・統合システム関連の対応状況と課題認識
  組み込み:統合か進む 4〜6割
    ビジネスモデル
    全体品質の確保

・電気法品安全法技術基準体系等の見直し
  「組み込みソフトウェアの安全性」が入ってくる
   (国際標準に書いてある)

・消費者教育推進法
  事業者、事業者団体の努力義務

・消費者事故などの調査機関の設置
  運輸は事故調査委員会を作ることが法律できまっている
  消費者庁が設置するもの
 →いままで以上に企業がしっかり作ったということ

・組み込み、クラウド、モバイルの実現に向けて
 全体システムを重視したハザード・リスク分析
  ・ハザードリスク分析のスコープ
  ・ハザード・リスク分析の潜在リスク
 品質の見える化、見せる化
  見える化、見せる化の対象
  見える化、見せる化の技術
   トレーサビリティマネジメント
   アシュアランスケース
  →D-Case:第三者が内容をみる

・関連する政府など(D-Caseのお客様?)
 ソフトウェア品質説明のための制度ガイドラインの策定
 自動車向け機能安全規格(26262)のガイドラインの整備
 トレーサビリティ管理基盤の開発
 TERAS
 スマートシステム検証技術協会(SVA)
 モバイルIIOT
 利用者TIDAコンソーシアム

・制度ガイドラインの公開について
  品質説明




D-CaseとSysML/UMLの連携

$
0
0
・実証実験
・D-Case作成

D-CaseとSysML/UMLの連携の実証実験

・実証実験の適用対象としたシステムの概要
 SysMLを用いたシステム開発の事例紹介
    ジェスチャする
     ↓
    Kinectを使って読み込み
     ↓
    PCで処理
     ↓
    ルンバの走り方が変わる

・開発プロセスと成果物
  分析
  システム開発
  ソフト開発
  製造
  運用

・分析フェーズ
  プロジェクトコンテキストの定義
    成果物:プロジェクトコンテキスト
    →D-Case:デモ用で十分
  ステークホルダー分析
    成果物:ステークホルダーリスト(ユースケース図)
    →D-Case:トップゴールのコンテキスト
  要求分析
    成果物:要求図、要求テーブル
      非機能要求安全性
    →D-Case:ゴールを達成するために満たすべき要求や
         どの要求とリンクしているか
         ゴール〜要求〜ブロックのトレーサビリティ確保
  システムコンテキスト定義
    成果物:システムコンテキスト
    →D-Caseトップゴールのコンテキスト

  ユースケースの特定
    成果物:SysML:ユースケース図
    →

・システム設計フェーズ
  ユースケース分析
    成果物:ステートマシン図
        アクティビティ図
    →D-case:

  システムアーキテクチャ設計
    成果物:ブロック定義図
        内部ブロック図
        構造図
    →D-case:要素を結びつけ?

・ソフトウェア設計フェーズ
  構造設計
    クラス図

  振る舞い設計
    ステートマシン図
    →D-case:ゴールの構造と振る舞い?

・製造
  成果物:部品、パーツ、ソースコード
    →D-case:成果物と?

・検証・妥当性確認とD-Caseの連携
    →D-case:検証・妥当性確認と?

・運用

考察
 D-CaseとSysML/UMLによるモデルベース開発の親和性は高い

・D-CaseとSysML/UML連携の構想
  作成負荷
  効果的な連携
 影響分析
 要求の立証カバレッジ分析    
 参照容易性
  表形式による表示    
 モデルからの展開
  モデル構造の展開

・実証実験
  時間がかかった
 論点
  記載する粒度および重複記載
  機能充足性の立証
  機能要求の立証の位置づけは?
    →指針を示さば迷いなくなる
  ディペンダビリティ属性の定義
  公開されているサンプルが少ない
  テンプレート

D-Caseの超小型人工衛星への適用

$
0
0
ディペンダビリティを見える化する手法?ツールにD-Caseってのがある。
今日、第3回D-Case実証評価研究会のはじめのほうを、慶応の日吉で聞いてきたので、
そのメモメモ

の第三弾、
「D-Caseの超小型人工衛星への適用」



・発表内容
 3つの工夫のもとにD-Case作成
 記述結果、インタビュー

・適用事例
 東京大学次世代宇宙システム
 山火事検地
 現在試験フェーズ
 背景:信頼性とコスト
  信頼性あるところを超えると、急激にコスト
  D-Caseで情報可視化

・記述の流れ
 V-モデルに沿って
 目的:トレーサビリティ、
  V-モデルの分解
    分解する観点
  各ゴールに対して、コンテキスト・えびでんす・モニタ
    保証する観点
    トレーサビリティの観点

・分解する観点
  段階的に定義
  抽象的な観点→具体的
   段階的にアシュアランスケースを記述
・保証する観点
   段階的にアシュアランスケースで保証
・トレーサビリティの観点
   情報がトレースできれいるか

記述結果

1Step
 5W1Hを定義→保証条件を定義
 保証する範囲を限定
  サブシステム定義

2Step
 トップゴールを決める
 アシュアランスケース
  機能の観点から分解
    ゴール
    最下層:ボトムゴール

3Step
  記述結果を定義
  保証する範囲を限定

レビュー結果
 記述結果が理解できるかどうかが大事

因果関係がないのに相関関係があらわれるケース

$
0
0
がまとめられていたので、メモメモ

■[統計][リスク]因果関係がないのに相関関係があらわれる4つのケースをまとめてみたよ(質問テンプレート付き)
http://d.hatena.ne.jp/takehiko-i-hayashi/20130418/1366232166

(以下太字は、上記サイトより引用)


(1) 偶然によるケース
(2) 因果の流れが「逆」のケース
(3) 因果の上流側に共通の要因があるケース
(4) 因果の合流点において選抜/層別/調整されてしまっているケース


にまとめられるらしい。

ビッグデータを襲うアンスコム

$
0
0
ビッグデータを使って、何らかの予測を行おうとした場合、
予測しようとする値が、複数の要因(変数)がある場合、重回帰分析を使ったりする(ほかのモノ使うときもあるけど)。
このとき、予測式は、でるかもしれない。
では逆に、仮説を立て、いくつかの要因(変数)から、重回帰で予測式が得られるかというと・・・

 重回帰分析だと、多重共線性(multi collinearity:頭を取るとmulti co マルチコ)があると、
うまく求まらない。
なので、変数間が独立していればいいが、因果関係があったりすると、強い相関が出るので、多重共線性により、うまくいかない。つまり、複雑な因果関係は、重回帰をつかってどうのこうのというのは、無理。

 複雑な因果関係があり、どのような関係で、値が決まってくるか、ある程度見える場合は、共分散構造分析を使う。これだと、因果関係のパス図を書けば、確かめられる(ただし、SPSS AMOSでは書きやすいが、Rでこれをやるのは、かなりたいへん)。ビッグデータを使って、何かを確かめたい場合、このような因果関係の複雑なメカニズムを知りたいことも多いだろうから、共分散構造分析は役立つ。

 しかし、共分散構造分析は、その名のとおり、共分散、相関を元に考えている。
 これは、線形の関係が成り立つときに成立する。
 線形の成り立たない2つのモノがあった場合、その相関、共分散は正しく出ない。
 ということは、共分散構造分析では、線形の関係が成り立たないと、分析が正しく出ない。
 (共分散構造分析だけでなく、重回帰でも、線形が成り立たないと、まずい)

 これは、「アンスコム」として知られる。具体的な例は、

 こちら http://sun.econ.seikei.ac.jp/~inoue/HPtemp/temp3.htm




ということは、ビッグデータで何でも解析できるというわけではなく、
重回帰を使う場合は、制限がある(線形&多重共線性がない)。
共分散構造分析も、線形でないといけない。
(SVMだと、カーネルトリックを使って線形でないものを取り扱える)

なので、「ビッグデータ使えば、なんでも解析、予測できちゃう!」と
いう考えに、アンスコムは冷や水を浴びせてしまう、それはそれは、まずい概念。
これが知られると、これからビッグデータで金儲けしようという人たちには、
困ったモンなわけだ。

でも、このアンスコムが書かれている本がこれ


アンスコム的な数値例で学ぶ統計的方法23講―異なるデータ構造から同じ解析結果が得られる謎を解く
http://www.amazon.co.jp/gp/product/4817194588


・・・うん、この題名では・・・
・・・ビッグデータは、安泰そうです(^^;)

なので、ビッグデータと来るとベイズ?なのかしら・・

$
0
0
前に、アンスコムのことを書いたけど、
そんなこんなで、ビッグデータをやっている人は、因果関係を示すには、
ベイズを使いたがるのでしょうか・・・
(もちろん、共分散構造分析(SEM)も使うけど)

最近のユニシス技報でも

ベイズ法を用いたノイズに頑健な高次元データの推定
http://www.unisys.co.jp/tec_info/tr115/11503.pdf

なんていうのが出ている。

マーケティング、ビッグデータ的には、ベイズの香りをさせないと、いけない時代なんでしょうかね(^^;)



 特に最近は、「ビッグデータ時代のマーケティング―ベイジアンモデリングの活用」という本が出て、著者の一人は、統計数理研究所長の樋口知之先生(最近、データサイエンティストについていろいろ発言している)なので、今後、ビッグデータなSIerさんに、もっともっと、ベイズ話が浸透しそう・・・(ちなみに、さっきの本、もう一人の著者は、筑波大大学院(東京キャンパスのほう)の佐藤先生)。

 もっとも、この辺の話題は、グラフィカルモデリングとして、近頃、いろいろ議論されているようですね。

 ただ、ビッグデータな人たちは、あんまり、グラフィカルモデリングの話って、取り上げてないような気がするんだけど、どうだろう・・・??
 ベイズちゃん、グラフィックちゃんなどのめがねっ子萌えキャラができれば、一挙にいくかもしれません!!
Viewing all 7292 articles
Browse latest View live