がんばれ!!しんちゃん
子育てから、音楽・ビデオ鑑賞などの趣味、学問や能力開発等生活全般に関する話題を断片的に書き綴る。
未来予測
未来予測と言えば、これまでは、過去のデータのトレンドから統計的に未来を外挿する方法がとられていたが、最近、事情が少し変わったようだ。
予測したい事象の発展を支配する法則が分かっている場合、その事象の現在のデータを初期条件として与えるだけで、未来を予測する。

2002年、日本の「地球シミュレータ」はニューヨークタイムズで、「コンピュートニック」と表現された。
人間の生き方・考え方やパラダイムまでも大きく変える可能性を持っていると評価されたのだろう。

あらゆる物が相互に影響し合っている自然を要素還元物理学とは全く違った方法で捉え直す事は、パラダイムの変革であるのだろう。

「複雑性の科学」というアプローチもあるが、実験法・解析方法を見出すのが困難である。

現実の物事は線形的に振舞うことも、平衡であることも稀である。
シミュレーションでは、非線形・非平衡の世界を扱える。

ベクトル型(シーモア・クレイが考えた方法で、メモリ部と演算部を結ぶパイプライン装置を使う)のスーパーコンピュータは高価なため、スカラ型(演算ごとのデータをメモリからプロセッサに運ぶ方式)コンピュータ複数を並列に繋ぎ、処理能力を上げる方式(パラレルコンピュータ)が登場したが、通信速度がネックになった。

約400億円、(旧)宇宙開発事業団、(旧)日本原子力研究所、(旧)海洋科学技術センターで「地球シミュレータ開発」を行った。
NTTが受注し、地球シミュレータ開発センターが設置された。
ベクトル型プロセッサ(8ギガ・フロップス)×8=64ギガ・フロップスと16ギガ・バイトの共有メモリを1まとめにしたものを1プロセッサ・ノードとする。

*フロップス(FLOPS)=1秒間に浮動小数点数演算が何回できるかという能力。


640個を配列し、理論最大演算性能は64ギガ・フロップス×640個=40.96テラ・フロップス。
ところが、米国が大騒ぎしたのは、この性能ではないと言う。
地球シミュレータがホリスティック(全的)であり、システムを丸ごとシミュレートできる可能性を持っていたからだ。

部分的にではなく、複雑に絡み合った要素間の相互作用を、高精度でシミュレートできる事が、要素還元的なパラダイムを覆す可能性を秘めていることが評価されたのだ。
地球の温暖化や環境汚染、地震・異常気象の予測・自動車の衝突安全性の設計・ナノ材料の開発等などをシミュレーションすることが可能。

一つの成果としては、2100年までの予測を行い、温暖化の強く出やすい地域とそれ以外の地域の分布を明らかにした。

人為的に温暖化ガス排出を与えた場合と与えない場合の比較をし、人為的に排出が温暖化の原因であるとした。

経済・社会問題のシミュレーションは、人間を基本構成要素とすれば、約60億人の相互作用を解くシミュレーションと考えられる。
しかし、経済や社会に大きな影響を与えるのは、政治家・経営トップ等の行動に基因することが多いため単純化することができる場合もある。
また、集団として超粒子的に扱うことで、モデル粒子数は極端に減らすことができる。
問題は、初期条件の獲得や条件付けが難しいことだ。
中でも個人情報が大きく作用することがあるようだ。

現在、地球シミュレータの性能は、世界一ではなくなった(米IBMの「BlueGene/L」が36.01TFLOPSを出した)が、文部科学省の主導で2010年までに、10(ペタフロップス)PFLOPS(=1京FLOPS)の「汎用京速計算機」を開発するプロジェクトが進行している。
「地球シミュレータ」の約250倍の演算性能だ。
国家戦略的意味も含め、米国に高性能のコンピュータを依存しないという方向は正しいと思う。
税金の無駄遣いだという声も聞こえるが、成果や利権が一部に偏るのは大きな問題だが、将来を考えること(未来志向)は、現在の生活を守ることと同時進行させるべきだろう。

ただ、悪夢の未来(フィリップ・K・ディックの描く「マイノリティ・リポート」のような近未来)が待っている可能性もないわけではない。

コンピュータの使い方の問題ではあるが...。



参考文献

「未来を予測する技術」佐藤哲也著(ソフトバンク新書)

「マイノリティ・リポート」フィリップ・K・ディック (ハヤカワ文庫SF)

参考WEBサイト

アメリカを驚かす日本の世界最速コンピュータ
http://www.icot.or.jp/FTS/REPORTS/H13-reports/earth_simulator.html

地球シミュレータセンター : The Earth Simulator Center
http://www.es.jamstec.go.jp/index.html

ITmediaニュース:「汎用京速計算機」は人体シミュレーションを目指す
http://www.itmedia.co.jp/news/articles/0509/28/news107.html

温暖化を救うか?スーパーコンピュータ|環境問題 エコビジネス:WEBマガジン「カーソル」
http://www.kersol.net/contents/500165/50016501

マイノリティ・リポート
http://www.foxjapan.com/movies/minority/
パレートの法則が崩れる領域
パレートの法則は、人間活動のあらゆるものに活用可能とされている。
80:20の法則等とも言われ、不良品の80%は全体の20%の不具合から生み出される等というような使われ方をする。
元々は、所得配分の統計的研究から発見された法則だ。


ABC分析を利用し、重要な順にA・B・Cの3つのランクに分け、パレート図(累積度数分布図)を作成することができる。

パレート図とは、QC7つ道具の一つで、データを層別し、値の大きい順に並べた棒グラフで表し、その累積百分率を折れ線グラフで示した図だ。
問題解決・改善等、意思決定に当たってどの項目が重要かを判断するのに使われる。

特にビジネスでは、パレートの法則は非常に便利なツールである。
例えば、書籍の販売を考えてみると、売れ筋の本を揃えておくことが効率の良い方法だ。売れない本は、スペースの無駄でしかない。

ところが、アマゾン等、オンラインショップでは、売れ筋意外の本の売り上げが、売れ筋本の売り上げを凌駕している。
いわゆるロングテイル現象だ。
パレートの法則が当てはまらない領域だ。

物理的空間の経費が不要(店舗がいらない)であること、検索エンジンの進歩(瞬時に調べることができる。検索経済という言葉もある)等、経済が数理経済理論通りに動く(インターネットは経済的制約条件を限りなく0に近づけつつある)ことが主要因のようだ。


UMLダイアグラム

UMLダイアグラム



ダイアグラムとは、あるシステムを複数の視点(ビュー)で表現した図。
視点を含めてモデルと呼ぶ。



静的

クラス図



システムとドメインにおける事物、及びそれらが互いにどのように関係し合うかを示す。

オブジェクト図



クラスのインスタンス、及びその相互の関係を示す。
各オブジェクトは、名前付きの長方形で表される。

コンポーネント図



システムのソフトウェアコンポーネントをモデル化したもの。
各コンポーネントは、左側に2つの小さな長方形が付加された長方形で示される。

配置図



コンピュータシステムの物理的な構成を示す。
システムにおける各コンピュータとデバイス、各コンピュータに属するコンポーネントを示すことができる。
コンピュータ(ノード)は直方体で示され、その中に各コンポーネントを置く。

動的

シーケンス図



システム内のオブジェクトがどのように相互に関係しているかを、時間軸に沿って視覚的に表現したもの。
オブジェクトは時間の経過に伴って上から順に並べられ、ダイアグラムは上から下へと流れる。
矢印は、オブジェクトからオブジェクトへ送信されるメッセージを示す。


アクティビティ図



手順と分岐を示すことによって、オブジェクトの振る舞い、または業務プロセスの過程で起こっていることを表す。
アクティビティは卵型で表示され、分岐は菱形で表される。

ユースケース図



システムの使用法を示す。各ユースケースは楕円で、各アクターは人間の形で表される。

ステートチャート図



特定の時間におけるオブジェクトの状態を示す。
状態は角の丸い長方形で表され、状態遷移はこれらの状態をつなぐ線で表される。

コラボレーション図



オブジェクトの相互作用を視覚的に表現する、もう一つの方法。
オブジェクトはダイアグラム中のどこに配置してもよい。
オブジェクト間のメッセージはオブジェクトをつなぐ線で表される。
メッセージの順序に従って、線に番号を付け、メッセージの性質に関連した情報を示す。

その他の機能



ステレオタイプ


既存のアイテム以外が必要なとき、新たに定義して使う。

ノート


不明確なものの記述に向く。

パッケージ


ダイアグラムの中の構成要素をグループ化。


オブジェクト指向



全てのものは、オブジェクトである。
オブジェクトは、属性と振る舞い(オブジェクトが実行する一連の操作)で構成される。
この操作と属性をまとめて機能(feature)と呼ぶ。

オブジェクト = クラスのインスタンス

概念


抽象化(abstraction)


 必要な部分のみ抽出して残りを排除する。

継承(inheritance)


 クラスからオブジェクト又は、(スーパー)クラスから(サブ)クラスへ特徴が受け継がれる。

多態性(polymorphism)


 クラスごとに操作の内容が異なっていること。

カプセル化(encapsulation)


 情報の隠蔽。
 操作の内容を隠し、インターフェイスによってユーザのアクセス制御をする。

メッセージ送信(message sending)


 メッセージ=操作の実行要求。
 複数のオブジェクトが相互に連絡を取り合うこと。

関連(association)


 複数のオブジェクト間には何らかの関連がある。
 多重度(multiplicity)も考慮する必要がある。

集約(aggregation)


 関連の一種。
 種類の異なる複数のオブジェクトから単一のオブジェクトが構成されていること。
 関連性が特に強い場合の集約をCompositionと呼ぶ。



利点


発生する関連の種類を予め把握しておけば、クライアントの問題の対象領域(domain)を明確化しやすい。

UMLの基礎概念

UMLの構造(Architecture)



アーキテクチャーとは、システムの構成要素とその機能、振る舞い、インターフェイス、組み合わせ等に関する決定事項を簡単にまとめたものを言う。
メタメタモデル層、メタモデル層、モデル層、ユーザオブジェクト層の4層から成る。


メタメタモデル層



UML構成要素全てを指定する言語を定義する。

メタモデル層



モデルに含めるものを定義する。
基盤、動的要素、モデル管理の3つのパッケージからなる。

1.基盤(Foundation)

・Core ... UMLモデルの構築に必要なものを定義する。
 抽象アイテム
 モデル要素(Model Element)、汎化要素(Generalizable Element)、分類子(Classifier)から成る。
 分類子は、クラス、コンポーネント、アクター、インターフェイス、サブシステム、ユースケース、シグナル、データ型等が

 具象アイテム(抽象アイテムのサブアイテム)
  インスタンス作成可。
  クラス、インターフェイス、関連(Association)、データ型等がある。

抽象構文(abstract syntax) ... パッケージはアイテムをクラス図に表示する。
整合規則(wellformedness rules) ... パッケージにはアイテムの使用規則が含まれている。
セマンティクス(semantics) ... パッケージはアイテムの意味に関する情報を提供する。

・補助要素 ... コアパッケージを発展させたもの
・データ型 ... Data Type。UMLが使用するデータ型を指定する
・拡張メカニズム ... Extension Mechanisms。UMLの拡張方法を指定する

2.動的要素(Behavioral Elements)
 4つのパッケージがある。

・共通の振る舞い ... Common Behavior
 動的要素に概念を提供し、その他のパッケージをサポートする。
 動的要素に提供される「概念」には、シグナル、リンク、関連終端(Association End)等がある。

・コラボレーション ... Collaborations
 ここでのコラボレーションは、分類子とその関連が特定のタスクを実行するときのやり取りを表す。
 コラボレーション図とユースケース図が当てはまる。

・ユースケース ... Use Cases
 ユースケースの概念の形式上の詳細を説明する。

・状態マシン ... State Machine
 ステートチャート図とアクティビティ図の形式上の詳細を説明する。

モデル層



 クラスを取り扱う作業はこの層に属している。
 モデル、サブシステム、パッケージを定義する。


ユーザオブジェクト層



例や特定のドメインのインスタンスを取り扱う作業。
ここでの「ユーザ」とはUMLユーザのことであり、システムのユーザではない。


UMLの拡張


 3つの既成の拡張メカニズムがある。
 これらは、メタモデル層の基盤パッケージの拡張メカニズムパッケージに含まれている。

ステレオタイプ


 UML構成要素を拡張して新しいクラスのインスタンスを生成するために負荷する文字列。

 ●依存関係
 ‹‹become››
 ‹‹call››
 ‹‹deroved››
 ‹‹friend››
 ‹‹extend››
 ‹‹include››
 ‹‹import››
 ‹‹metatarget››
 ‹‹instanece››
 ‹‹semd››

 ●分類子
 ‹‹metaclass››
 ‹‹powertype››
 ‹‹process››
 ‹‹thread››
 ‹‹utility››
 ‹‹stereotype››

 ●クラス
 ‹‹type››
 ‹‹implementationClass››


 ●コンポーネント
 ‹‹document›› ‹‹executable››
 ‹‹file›› ‹‹table›› ‹‹library››

 ●汎化
 ‹‹inherit›› ‹‹subclass››
 ‹‹private››

 ●パッケージ
 ‹‹façade››
 ‹‹system››
 ‹‹stub››
 パターン
 ‹‹framework››
 ‹‹topLevelPackage››

 ●その他のステレオタイプ
  ‹‹invariant››
  ‹‹postcondition››
  ‹‹precondition››
  ‹‹requirement››
  ‹‹create››
  ‹‹destroy››

 ●グラフィックのステレオタイプ
  クリップアート等を使用。


制約(constraint)


 関連、リンク終端、汎化、要求の条件を定義するもの。
{or}は、この関連に影響を及ぼす関連が一つだけ存在することを示す。
{implicit}は、この関連が概念的な関連であることを示す。
{parameter}は、このオブジェクトがパラメータであるために可視であることを示す。
{self}は、オブジェクト自身が要求のディスパッチャであるために可視であることを示す。
{global}は、リンクに関してオブジェクトがグローバルスコープやローカルスコープにあるために可視であることを示す。
{association}は、オブジェクトが可視なのは関連があるためであることを示す。
 複数の汎化は、{complete}(全てのサブタイプが指定されている)かまたは、{incomplete}(その他のサブタイプを追加できる)で、{overlapping}(一つ以上のサブタイプがインスタンスタイプとして機能)又は、{disjoint}(一つのサブタイプがインスタンスタイプとして機能。デフォルト)になる。
 要求が決まった順序はなく、多数のターゲットインスタンスに送られる場合、{broadcast}になる。
 また、多数のインスタンス全てが値を返し、その戻り値の過半数を占める値に決定される場合、{vote}になる。

タグ付き値


 既成のタグ付き値は、分類子、コンポーネント、属性、インスタンス、操作に適用する。
{documentation=}は、あらゆる要素に適用でき、右辺には、説明やコメントを挿入する。{location=}は、分類子に適用する場合、右辺には、その分類子の属するコンポーネント、コンポーネントに適用する場合、右辺には、コンポーネントの属するノードを挿入する。
{persistence=}は、要素の状態が永続的であるかどうかを示す。右辺の値は、維持されるならpermanentで、破棄されるならtransitory。
{semantice=}は、分類子又は操作の意味を指定する。
{responsibility=}は、分類子の義務を指定する。 






開発の方法論




ウォーターフォール方式1


 分析 → 設計 → コード化 → 配置が順番に行われる。

 ●問題点
1.作業を区分しなければならない。
2.プロジェクト進行中に明らかになった情報を反映しにくい。
3.分析や設計に十分時間をかけられない。


新しい方式


 開発の各段階での協調作業に注目した方式。

 ●問題点
1.各段階を区別してしまうことがあり、システムにクライアントの要求が反映されない。


開発チーム


分析者、設計者、プログラマ、システムエンジニア

求められること



1.開発チームが、解決すべき問題を十分に把握していることの確認。
2.開発チームのメンバーに適切な役割を割り当てていること。
3.役割を割り当てられたメンバー間のコミュニケーションを促進すること。
4.フィードバックをひとつの開発段階に限定しないこと。
5.不要な書類を減らし、開発作業の進捗状態をクライアントに伝えること。

GRAPPLE



Guidelines for Rapid APPLication Engineering

状況に応じて改変可能な柔軟な考え方をまとめたもの。

RAD3(又はRADDD)


五つのセグメントで構成されており、各セグメントは、複数のアクションで構成されており、ひとつひとつのアクションから青果物が得られる。


1.要求の収集(Requirements Gathering)


 最重要セグメント。

・業務プロセスの洗い出し
・ドメイン分析の実施
・協調して動作するシステムの特定
・システムの要求の洗い出し ... JAD(Joint Application Development)セッション
調整役はファシリテータ(facilitator)
・クライアントへの結果報告

2.分析(Analysis)


・システムの用途の把握 ... ユースケース図
・ユースケースの洗い出し ... ユースケースの手順書
・クラス図の洗練 ... クラス図
・オブジェクトの状態遷移の分析 ... ステートチャート図
・オブジェクト間の相互作用の定義 ... シーケンス図とコラボレーション図
・協調して動作するシステムとの統合 ... 配置図、データモデル(オプション)


3.設計(Design)


・文書化の開始 ... 文書の構造
・テストの設計 ... テストプログラムのスクリプト
・ユーザーインターフェースの設計とプロトタイプ化 ... ユーザとのJADセッション、プロトタイプのスクリーンショット
・開発計画 ... 配置図
・コンポーネント図の作成 ... コンポーネント図
・オブジェクト図の洗練 ... オブジェクト図とアクティビティ図


4.開発(Development)


・コード作成 ... コード
・コードのテスト
・ユーザーインターフェースの作成、コードの接続、テストの実施
・文書の感性

5.配置(Deployment)



・バックアップと復元の計画







MIXIで、○○○を始めることになった
家内が「MIXI,mixi,ミキシー、みーきーしーいーっ」というので、MIXIに登録することになった。

MIXIに登録するには、誰かから招待状を貰わなければならない。

招待状は、すでにMIXIに登録している友人から貰えばよいのだが、そっち系の友人がいない場合、"あきらめるのが一番だ"。
家内にそう言ったところ、ひどくけなされた。

2チャンネルを探してみると、ソーシャルネットワークサービスのスレッドの中にMIXIのスレッドを見つけた。
「mixiに招待するよ」とある。
覗いてみると、
以下のような依頼書(?)に何人かが書き込んでいる。


*** 名前:******** :2006/10/03(火) 20:05:04 ID:******
【テンプレは読んだか】 はい
【有効なアドレスは2個あるか】はい  ← MIXI登録用と招待者との連絡用
【うp用の画像は用意したか】 はい  ← 必ず1枚は用意する。
【職業】 会社員  ← 別に会社員でなくてもよい。
【年齢】 31   ← 年齢は、31でなければ登録できないわけではない。
【性別】 男  ← 女でもよいが、どちらでもない人は不明。
【連絡用メールアドレス】*****@****.**.** ← ここには、連絡用メールアドレス。
【現住所】 東京都 ← たぶん外国でも良いだろう。
【出身地】 東京都 ← たぶん外国でも良いだろう。
【良く行く板】 ゲーム、アウトドア  ← どこでも勝手に行ってろ
【mixiに参加して何をしたいか(具体的に)】  ← 目的ははっきりした方がよい。


 *** 都合により伏字とさせて頂いております。


「テンプレ」とは、招待状を貰う際の注意書きのようなもの。

「有効なアドレス」とは、使えるメールアドレスのこと。
 MIXI登録用メールアドレスと連絡用のメールアドレス。
 連絡用メールアドレスは、フリーメールや転送メールサービスを使うべきだと書いてあった(どこに書いてあったか忘れた)。

「うp用の画像」とは、プロフィールで使う写真などのこと。
MIXIは、人間は少ないようだ。たまに犬や恐竜も見かけるが、驚いたのは、ぬいぐるみがブログを書いたりすることだ。


2チャンネルを使いたくない場合、どうすればいいだろう?
まず、Googleなど検索エンジンのキーワードに「MIXI」を入れる。
そして、もう一つ趣味や関心事をキーワードに追加する。
例えば、 「MIXI 花」等とする。
ピックアップされたものの中から、「MIXI」と「花」が関係するブログを見つけて、その管理人に頼んでみる。
運がよければ、その「花」関連のブログで「MIXI招待状を配布します」と謳(うた)っている場合がある。
同好の士を募って、MIXIで突っ込んだ会話をしようということだろう。
この方法で招待されたら、後ろめたさもない。

それにしても、どうしてMIXI参加者が増え続けるのだろう?
現在、参加者は、200万人を超えているらしい。
やはり、日本人の特徴なのか?