Twitterのまとめの中に、形式仕様とDbC（契約による設計）の話が出てきたり、よく、ICONIX（資生堂？・・・そりゃ、ICONIQ)の話とかでてくる。
読んでる人には、？？？となってしまうかもしれないので、ここで、その辺の、開発方法論の話をざっとまとめてみる。
ざっくりなんで、ツッコミどころ満載、不正確です。
■構造化手法、データ中心指向、形式仕様
設計手法としては、まず構造化手法がでてきて（デマルコ：ＤＦＤを作るやつ）、その後、いやプロセスでは変更が大きいので、データに着目しようよ、っていうことで、データ中心になっていった（ＤＯＡ、たまに出てくる佐藤正美氏は、このＤＯＡの立場）。
これに対して（対してはいないか、同時並行に？）、プログラムを厳密に定義し、高品質なソフトを作ろうと考える研究、実践があった。
元は、Hoare論理なんかで、これを形式仕様記述という形で言語化したものに、VDMやZがある。
設計論のほうでは、メイヤーが、これらの考えを受けて（たしか、メイヤーはＺの研究もしてた？）、事前条件、事後条件、不変条件を定義する、契約による設計（ＤｂＣ）を提唱した。
■オブジェクト指向
そして、データとプロセスをひとまとめにして、カプセル化（局所化）することによって、変更に柔軟なソフトを作ろうとする考えが出てくる。これがオブジェクト指向。
SmallTalkや、（上述のメイヤーが作った）Ｅｉｆｆｅｌという言語、ランボー、ブーチ、ヤコブソンのスリーアミーゴーズ（警官ではない）による設計論が出てきた。とくに、設計論の図示の分野では、スリーアミーゴーズによる標準化（妥協の産物？）のＵＭＬが出てきた。
このＵＭＬを形式仕様化しようとしたのが、ＯＣＬ。
ただし、ＵＭＬは、設計の図（ＵＭＬ・・・Ｌはランゲージなんで、言語と彼らは言い張るわけだが・・）を決めただけで、どういう手順で行うか？ということについては決めていない。
この設計手順、もっと大きく言うと開発手法として、ＲＵＰが出てきた・・・が、これは、たいへん。重い。そこで、軽量化したのがＩＣＯＮＩＸ（らしい）。
■コンポーネント指向へ
オブジェクト指向において、再利用まで考えると、オブジェクト、クラスという粒度は細かすぎる。
そこで、もうちょっと粒度を上げた、コンポーネントという概念で考えようという流れが出てきた。
これがコンポーネント指向。
（上記のＯＣＬのような）ＵＭＬと形式仕様をあわせたような形で、コンポーネント化を試みるカタリシス手法（Catalysis）、そのカタリシスをベースに、開発方法論を述べた「UMLコンポーネント設計」に見られる開発手法である、UML Componentsが、コンポーネント指向の一翼を担っている。
もう一翼としては、ＵＭＬから、ソース自動化？を試みたＭＤＡ（モデル駆動開発）と、プロダクトライン開発をベースにコンポーネント論を展開するKobrAがある。
■コンポーネントのほかに・・・
おぶっじぇくと指向における再利用等の生産性向上は、
コンポーネントのほかに、ソフトウエアパターンという手法がある。
パターン化です。設計レベル、分析レベル、実装レベルで、いろんなパターン化がありえます。
実装レベルでは、ＧｏＦによるデザインパターン、分析でのアナリシスパターン、アーキテクチャ全体としてのDDDとか・・
そして、実装面では特に、フレームワークが出てきて、ＭＶＣやＤＩという考え方や、Tomcat,Struts,Spring・・・などの実装方法が出てきた。
開発環境も、Eclipseに代表される（あ、Visual Studioも）ＩＤＥが出てきて、生産性向上に役立っている。
■形式仕様は・・・
ＵＭＬは、生産性を上げるため、分かりやすくするという方向に行ったが、
その反対？に、生産性を上げるため、高品質なものをつくる、そのために厳密に定義するという形式手法という方法が（先ほど言ったように）ある。
形式仕様は、ひとつは、形式仕様言語（ＶＤＭ，Ｚ）という方向に行ったが、
もうひとつ、モデル検査という方向にも発展していった。これは、システムをクリプキ構造によりモデル化して、時相論理や、ＣＴＬ（計算機論理）によって、モデルが満たすべき性質を記述し、本当にモデルが、それを満たすかどうか確認するという、手法である。
そしてこの形式手法をＵＭＬと融合させたのがＯＣＬって話は、さっきした。
＜＜参考文献＞＞
UML – a tutorial
http://www.sci.brooklyn.cuny.edu/~kopec/uml/uml_tutorial.pdf
（ＰＤＦです）のFigure 1 Some of the influences on UML.
アクセス
トータル
ランキング
