最近、このブログでやっている
●各種ダイアグラムの一貫性について
●システム開発に必要なもの（システムの最小単位）
●並列処理と一貫性
の話を、以下のサイトにまとめました（といっても、ブログのリンクだけど）
システム開発における「最小単位」とその連結法
http://www.geocities.jp/xmldtp/index_system.htm
実は、この３つの話、つながっているんです。
■システム開発に必要なもの（システムの最小単位）
ここでは、まず「システム開発に必要な最小限の情報はなにか？」という話をしています。
とくれば、ふつうは、チャーチのテーゼを出してきて、原始帰納的関数から、複雑なプロセスを作り出して行けるという話にもっていく（計算論 計算可能性とラムダ計算みたいなかんじ）。
だけど、実際、チャーチのテーゼのように、入力と出力が決まれば、プログラムが書けるのか？っていうと、書けない。
３に４を足して５をかけたものを出力してください。
といわれても、「どこに？」となってしまう。
まあ、常識的に考えれば、コンソールだが、Webのページかも知んないし、ファイルかもしんない。ということで、出力するメディアがきまんないと、書きだせない。
一方処理については、条件や順番が大事。
３と５を入れ替えて、５に４を足して３をかけたものは、ぜんぜん違う値になる。
なので、順番大事。
そうすると、前に書いたように、プログラムを記述するには、
・データ（メディア、型、値＝変数と定数）
・プロセス（入力データ、出力データ、起動順序・条件）
で、逆にこれが決まってくると、プログラムにかけたり、書けない理由がわかったりする（出力、入力を行うライブラリ、フレームワークがない）。
■各種ダイアグラムの一貫性について
では、
・データ（メディア、型、値＝変数と定数）
・プロセス（入力データ、出力データ、起動順序・条件）
を記述したものはあるのか？という話になるが、ある。
それが業務流れ図である。
では、業務流れ図から、プログラムを起こせるのか？起こせるとした場合、どんな情報が必要になるのかというのが、次の話題である。
このとき、
・業務流れ図に一貫性があり
・入出力メディアを実現するライブラリ、フレームワークが存在すれば
プログラムを起こせるという話を、ここでは展開していく。
プログラムを生成するため、業務流れ図などをRDBに入れ、一貫性チェックを行い、すでに登録してあるフレームワークの流れ図（も図なのでRDBに入る）合成していくという話だ。
実は、プログラムだけでなく、UMLなど、ほかの図も生成できる。
■並列処理と一貫性
ここでは、上記につくったダイアグラムがはいったRDBの応用になる。
並列処理をさせたとき、一貫性を持たせるには、どうしたらよいか？
これは、あるプロセスがあるデータを読み込み中のときに、ほかのサイトから、書きだし、更新を行わないことによって防止できるが、このことは、上記のRDBから検索可能なのか？という話を展開していく。
なお上記２つが、大学院修士の論文にしようとして、結局すべて捨てた（ゴミ箱行き）お話、最後の「並列処理と一貫性」が新作ということになります。
ってなことで、明日から３つをテキトーに書いていきます。
アクセス
トータル
ランキング
