制約プログラミング落穂拾いの最近のブログ記事

これまで数回にわたって制約プログラミングの最大の特徴である「宣言性」に関連して実用システムの開発に用いる際の課題について書いてきました。今回もその続きを、と思ったのですが、ちょっと寄り道をして、制約プログラミングを用いたシステム開発の見積について書きたいと思います。

ソフトウェアの見積が困難なことや、見積手法として様々な方法が提案されていることはご存知のことと思います。制約プログラミングを用いたシステム開発の場合、見積をする上で何が変わってくるのでしょうか。

さて、前回に引き続き、制約プログラミングを用いて実用的な問題に取り組んだときに直面する課題を具体的に見ていきます。今回扱うのは以下の問題です。

• 問題を表現できたとして、解をうまく求めることができるだろうか。ここで「うまく」というのには、(a)実用上許容できる時間内に、(b)実用上許容できる品質の解を求める、という2つの側面が含まれます。

さて、今回はいよいよ制約プログラミングを用いて実用的な問題に取り組んだときに直面する課題を具体的に見ていきます。

なお、前回も述べたように制約プログラミングのさまざまな機構の実装は処理系により異なります。従って具体的な機構の説明の部分は、あくまでも例示に過ぎないことを予めお断りしておきます。例示にあたっては、（当然のことですが）自分が実装を知っている処理系を前提としています。

前回、その課題が以下のようなものであることは既に述べました。

さて今回は、制約プログラミングの最大の特徴であり、メリットであるはずの「宣言性」、問題の定義と問題の解法の分離が、ソフトウェア開発の現場でどのような意味合いを持つかを具体的に考えて行きたいと思います。

なお、制約プログラミングのさまざまな機構の実装は処理系により異なります。従って具体的な機構の説明の部分は、あくまでも例示に過ぎないことを予めお断りしておきます。例示にあたっては、（当然のことですが）自分が実装を知っている処理系を前提としています。

宣言的なプログラミングでは、プログラムは問題を解くための処理の手順を書くのではなく、問題に存在する制約、即ち変数の間の関係を記述するだけです。

制約の記述をするためのシンタクスは制約プログラミングの環境により異なりますが、ここでは例えばC言語によるライブラリを想定します。この場合、

制約プログラミングの定義は色々と考えられるでしょうが、恐らく落とすことのできない特徴の一つとして必ず含まれるのは「宣言性」という特徴ではないでしょうか。今回から数回にわたって、「宣言性」について思うところを少し書いてみたいと思います。もっとも「宣言性」は非常に奥の深いテーマですから、ここで触れるのは、実際に制約プログラミングを実用的な問題の解決に使ったり、他人に説明したりした経験から私が個人的に感じたことに限り、また書き方はインフォーマルなものにしようと思います。

山崎です。

今回は9/19,20に青山学院大学で開催されたスケジューリング・シンポジウム2008（主催：スケジューリング学会）に参加して、制約プログラミングについて感じたことを書こうと思います。ものづくりAPS推進機構(APSOM)も協賛団体として名を連ねていますし、APSOM/PSLXに関連しての感想もありますが、そちらはまた別の機会に。

今回のシンポジウムはスケジューリング学会の創立10周年記念ということで、特別講演が2つ、その間にはパイプ・オルガン演奏（J.S.バッハのコラール・プレリュードとプレリュードとフーガを各1曲）という豪華なイベントもありました。

こんにちは、山崎です。

このカテゴリでは、NDiSでずっと取り組んできた制約プログラミング技術に関連するちょっとした話題について、フォーマルにならずに書いていきたいと思います。

初回の今回は、NDiSと制約プログラミングの関わりについて簡単に振り返り、現時点で私が感じていることを書きとめておこうと思います。