初めてのＲｕｂｙを読む その３４ ７．１

「初めてのRuby」を読むの続き

今日から
７章　メソッド

７．１　メソッド呼び出し
から

---

■７章　メソッド

・メソッド：Ｒｕｂｙにおいて手続きをモジュール化し、再利用するための仕組み
　　オブジェクト指向のメッセージ送信と
　　構造化プログラミングのサブルーチン
　両方の役割

・関数型メソッド
　　オブジェクトとは無関係に呼びさせる

---

■７．１　メソッド呼び出し
・Ｒｕｂｙプログラムにおけるすべてのデータはメソッドを持っている
　　→どんなメソッドを持っているかは、クラスによる
・Ｒｕｂｙプログラミングで中心的な役割を果たすのがオブジェクトに
　対するメソッド呼び出し

・メソッドを呼び出すには、レシーバー、メソッド名、引数を以下のように書く

　　　a.some_method(1,"str")
　　　a::some_method(1,"str")

　クラスメソッドを呼ぶ場合を除いて、第一のスタイルが主流

---

■７．１．１　括弧の省略

・引数をくくる括弧はあいまいさを生まない限り省略可能

---

■７．１．２　メソッド連鎖

・メソッドは必ず何らかの値を返す
　　→メソッドの返り値ないし戻り値という
　　→返り値に対してメソッドを呼ぶことも可能
　　　　　→メソッドチェーン

---

■７．１．３　レシーバーの省略

・メソッドを呼び出すレシーバーを省略することができる
　　→この場合は、デフォルトのレシーバーである
　　　selfに対してメソッドが呼ばれる
　　　　　→C++,Javaなどのthis

・擬似変数selfは常に「現在のレシーバー」をさしている

・privateメソッドは、常にレシーバーを省略形式で呼び出す。


・レシーバー省略とローカル変数
　引数をもたないメソッドのレシーバーを省略すると、
　ローカル変数の参照と見分けつかない
　　　→ローカル変数優先
　関数的メソッドでも形式的にはレシーバーを持っている

・組み込み関数
　どこからでも呼び出せる便利な関数メソッド
　Kernelモジュールのメソッド

---

■７．１．４　引数展開
・ * 修飾により、配列に格納された値を引数リストに
　展開できる

・Ｒｕｂｙ１．８では、 *　付き要素は引数リストの最後
　Ｒｕｂｙｉ．９では、出現位置、回数ともフリー
　配列から引数リストへの自動的展開は行わない


・関数型メソッド
　非オブジェクト指向的に用いられるメソッド
　レシーバーを持たない手続き

ＰＭＢＯＫのお勉強 その３５ － ６．６

今、

プロジェクトマネジメント　知識体系ガイド（PMBOKガイド）第４版
http://www.amazon.co.jp/dp/1933890681

のお勉強をしています。

前回は６．５章だったので、今回は６．６章です

---

■６．６　スケジュール・コントロール

＜＜インプット＞＞

・プロジェクトマネジメント計画書

・プロジェクトスケジュール

・作業パフォーマンス情報

・組織のプロセス資産


＜＜ツールと技法＞＞
・パフォーマンス・レビュー
　　　アーンドバリューマネジメント（ＥＶＭ）採用の場合
　　　　　　スケジュール差異（７．３）
　　　　　　スケジュール効率指数（７．３）
　　　クリティカルチェーン採用（６．５）の場合
　　　　　　バッファ

・差異分析
　　　スケジュールベースライン（６．５）との差異


・プロジェクトマネジメント・ソフトウェア


・資源平準化
　　　６．５

・Ｗｈａｔ－ｉｆシナリオ分析
　　　６．５


・リードとラグの調整


・スケジュール短縮
　　　６．５

・スケジューリングツール



＜＜アウトプット＞＞

・作業パフォーマンス測定結果
　　ＷＢＳ要素、特にワーク・パッケージと
　　コントロールアカウントにて算出した
　　スケジュール差異（ＳＶ）とスケジュール効率指数（ＳＰＩ）
　　を文書化して報告


・組織のプロセス資産更新版
　　以下のものがあるが、これに限定されない
　　　・差異の原因
　　　・選択した是正措置とその選択理由
　　　・プロジェクトのスケジュールコントロールから得られるその他の教訓など

・変更要求


・プロジェクトマネジメント計画書更新版
　　以下のものがあるが、これらに限定されない
　　　・スケジュールベースライン
　　　・スケジュールマネジメント計画書
　　　・コスト・ベースライン


・プロジェクト文書更新版
　　以下のものがあるが、これらに限定されない
　　　・スケジュール・データ
　　　・プロジェクト・スケジュール

UMLなどの図に描くと、あいまいでなくなるという「あいまい」の定義って、あいまいじゃない？

「UMLに描くと、あいまいでなくなる」

って、よく聞くじゃないですか・・・え、聞かない？
じゃ、検索してみて！
「UML あいまい なくなる」でけんさくすると、

　　・あいまいでないか、
　　・あいまいさが残る

っていう表現になる。前者は、ないって言い切っているし、後者も、あいまいがないからこそ、残っている部分もあるという表現になるので、どちらも、「あいまいがなくなる」という前提で書いている。

　問題はこのとき、「あいまい」の定義は何？
　これが判らなければ、「あいまいさがなくなる」って言っても意味はない。

ここで

１とおりにしか解釈できないことである
　というのなら、ＵＭＬの意味はない。
　いきなりプログラム言語で書いてしまったほうが、曖昧さはない。コンピューターは何通りにも解釈して、恣意的に結果を出すということはないのだから・・
　Ｊａｖａとかで記述し、細かいところはダミーモジュールにして、シミュレーションしたほうが早い。


情報を網羅できる
　ＵＭＬのほうが、欠落している。ＵＭＬが出る前の業務フローのほうが、画面、帳票などの出力先が明示されるので、情報量がある。

情報が整理される
　整理という観点なら。Ｅｘｃｅｌに書いたほうが整理される。


情報が見える化できる
　ＵＭＬじゃなくっても見えるか出来るし、もし、見える化命なら、ユースケース記述なんていう、記述にたよるのは、おかしいよね！

・・・あいまいの定義が、一番あいまいな気がする・・・
なんか、あいまいという言葉をあいまいに使うことにより、
「ＵＭＬはあいまいでない」ということに信憑性を持たせているんじゃないかなあ？
（あいまいの定義があいまいだと、あいまいでないかどうかはわからない）


構造化手法より、あいまいでないことは、どのように証明できるのだろうか？
少なくても「情報を網羅できる」「情報が見える化できる」という意味では、
構造化手法より、劣るよね・・・

世界コンピュータ将棋選手権で優勝した将棋ソフト「Bonanza」の遊び方

Bonanzaは、窓の杜にある

Bonanza
http://www.forest.impress.co.jp/lib/game/puzzle/tblegame/bonanza.html

の右上にあるＤｏｗｎｌｏａｄをクリック

ＺＩＰファイルを保存して、それを解凍。
Windowsの場合、解凍したフォルダをどんどん降りていくと、
winbinというフォルダがある。
その中のフォルダにCsa.exeというのがある（歩のアイコン）ので、
ダブルクリック。

起動すると、２つのウィンドウが出る。将棋版のウィンドウのほうで、
playをクリックすると、こんなかんじに

なるので、startを選択。すると

というダイアログが出る。先手でよければ、ＯＫボタンクリック

すると、将棋のこまが適当に動かせる。
動かしたいこまをドラッグ＆ドロップ。
コンピュータが手をさすと、ぴこ！とかいうかんじの音が出る。

詰まると、なんかダイアログが出る。
playメニューの横のFileメニューにexitがあって、終わらせられる。