制約プログラミング：方法論と事例
Download
Report
Transcript 制約プログラミング：方法論と事例
制約プログラミング：方法論と事例
NTTデータセキスイシステムズ
システム開発統括部第一開発グループ
山崎 雅史
http://www.constraint.org
Copyright(c) 2006 NTT DATA SEKISUI SYSTEMS Co,ISAC,Inc.
本発表の構成と内容
目次
1.
2.
3.
4.
5.
背景
開発方法論からみた制約プログラミング
開発事例の紹介
開発プロセスからみた事例の評価
まとめと今後の課題
参照文献
内容
制約プログラミングを、実用的なソフトウェア開発プロジェクトでの利用という実務家の立
場で扱う。
プロジェクトで制約プログラミングを使う場合のメリット・注意点を開発方法論の観点から
整理。
実際の開発事例について、開発プロセスを中心に紹介。
制約プログラミングが実用上非常に有効な技術であることを検証。
問題解決技法としての側面も、開発プロセスに影響を及ぼす範囲で言及。
2
Copyright(c) 2006 NTT DATA SEKISUI SYSTEMS Co,ISAC,Inc.
1.背景
Copyright(c) 2006 NTT DATA SEKISUI SYSTEMS Co,ISAC,Inc.
解法か開発手法か
制約プログラミングは、「難しい問題」を解くための技術と考えられている。
問題解決手法とした見た場合、適用可能な問題領域が共通する手法が競合手法として考
えられる。
競合技術の例
LP(線形計画法), MIP(混合整数計画法),タブーサーチなどのメタヒューリスティクス, NN(ニューラルネット
ワーク), GA(遺伝的プログラミング)などの進化論的手法
制約プログラミングの定義には揺れがある。
狭義では制約伝播手法をベースとした技術に限定される。典型的なのは演算領域をFD(有限領域)に限定し
た手法。cf.[BARTAK98]
制約プログラミングをパラダイムとして捉える視点もある。この場合には、宣言的な制約を用いた問題のモデ
ル化の側面が重視され、様々な解法が包摂される。cf. [山崎01]。また、パラダイムとしての制約充足問題に
ついては、例えば[西原97]参照。
実務上は定義の問題には拘泥しないが、「パラダイムとしての制約プログラミング」が実用上有効
かどうかを検証することは必要。
解法として優れていることは、実用的な開発手法であることとは別。
制約プログラミングは「実用的な」技術なのか？
イノベーションを強調することだけでなく、生産性の高い、安心して使える技術であることの
確認も必要。
4
Copyright(c) 2006 NTT DATA SEKISUI SYSTEMS Co,ISAC,Inc.
実務家の視点から
実用性は、以下の視点から考えなくてはならない。
開発者にとっての効率：「使いやすさ」「生産性の高さ」
ユーザーにとっての効率：「費用対効果」
実務家にとっては、実際の開発プロジェクトの中でうまく利用でき、結果が出せることが重
要。
ますます強まる開発サイクルの短期化に対応できるか？
モデル化や実用性の検証にじっくりと時間をかけていられない。
投資した時間(工数)対得られる成果の観点も重要。
「難しい問題」に取り組むこともあり、見積り精度への影響も考慮すべき。
単なる解法としての性能の優劣だけを論じるのは不十分
ここでは開発方法論上、制約プログラミングを使うことの持つ意味合いを確認したい。
5
Copyright(c) 2006 NTT DATA SEKISUI SYSTEMS Co,ISAC,Inc.
開発方法論からの検討の先行事例
解法としての視点が先行し、開発方法論的な検討は必ずしも多くない。
制約プログラミングの開発方法論的な検討の先行例：
[CHIC95] DassaultとBullによる “CHIC Lessons on CLP Methodology”
[FRON94] Fron “Programmation par contraintes” の一部（第9章）
自社の成果報告の中での評価報告：
[森95]「制約ベース的アプローチによる勤務計画・工程計画立案システムの設計」
開発方法論から制約プログラミングに言及している例(国内)：
[青木93] 「オブジェクト指向システム分析設計入門」
6
Copyright(c) 2006 NTT DATA SEKISUI SYSTEMS Co,ISAC,Inc.
2.開発方法論からみた制約プログラミング
Copyright(c) 2006 NTT DATA SEKISUI SYSTEMS Co,ISAC,Inc.
制約プログラミングを使ったソフトウェア開発
フェーズ
特徴
提案
プロトタイプによる要件の確認、実現可能性の検討。
設計・開発
プロトタイピングから実システムへスパイラル型の繰り返しで機能を追加していく。
他のシステムとのインタフェース、ユーザーとの対話のためのグラフィカルインタフェースな
どの開発については、通常のシステムとの違いは大きくない。
テスト
実データを用いたチューニングによる解品質の向上。
運用
条件変更への対応。インタフェースの変更への対応が比較的柔軟に行える。(制約条件の
抽象化：インタフェース・フォーマットと内部表現の分離)
プロトタイプ手法との相性は良い。
プロトタイピングのツールとしては強力。
ユーザーに対する説明がしやすいモデルが作れる。
「説明原理」としての制約プログラミング cf.[橋田94]
スパイラル開発との相性が良い。
プロトタイプ段階での実データを用いたフィージビリティの検証、実システム開発での実データを用
いた性能向上が成功の鍵。
性能改善や状況の変化に対応した条件変更に対して柔軟で頑健。
初期開発だけでなく、保守・改良まで考えた場合に、長期間にわたり使い続けられるシステムを提
供できる。
8
Copyright(c) 2006 NTT DATA SEKISUI SYSTEMS Co,ISAC,Inc.
[参考]FP(ファンクションポイント)の観点から
FP法[児玉99]からみた場合の特性は、解法自体ではなく、問題領域の固有性に由来する
部分が大きい。
他の解法でも対象問題が同じなら、ほぼ同じ傾向になる。
FP法の精度を上げるためには、モデリングが重要
制約プログラミングは有利。
入出力(特に入力)のインタフェースは複雑
様々な情報を集約し、多様な条件を考慮した計画作成を行うことから。
システム特性の「処理の複雑性」「変更の容易性」→重み大。
「性能条件」「エンドユーザーの効率性」→目標設定が重要。
システムの規模にインパクトを与える因子となる。
制約に関連したメトリクスを追加することを検討すべき。
制約の数・密度・探索空間や解空間の大きさ・密度など。
主として「処理の複雑性」に関連し、より厳密な評価が可能になる。
現状では定性的な考察のみ、今後定量的な検証が必要。
9
Copyright(c) 2006 NTT DATA SEKISUI SYSTEMS Co,ISAC,Inc.
開発プロジェクトで制約プログラミングを用いる際の留意点
プロジェクトの中での量的な割合
全体のプロジェクト規模は様々だが、制約プログラミングを用いた問題解決プログラムは、システム全
体の一部に過ぎない。
制約プログラミングを用いた設計・実装を行うのは少人数。
経験上、スタンドアロンシステムであっても開発工数の過半は各種インタフェースの開発にあてられる。
他のシステムとのインタフェースや、ユーザーインタフェースの設計・実装の重要性が、通常のシステ
ムよりも低いということはない。
フィージビリティはプロトタイプ時点で解決すべき問題で、実システム開発は通常と同じ。
手法の習得・技術移転の問題
習得の困難さが言われるが、程度問題。
習熟には時間が必要なのは他の解法も同じ。
他の技法に比べて、直感的なわかりやすさがあるため、ハードルは低い。
実装プログラミング言語の壁はない。
当初論理プログラミングベース(Prologなど)だったが、現在の商用の開発ツールの主流はC++, JAVAなどのクラ
スライブラリ。
技術移転の問題はある。特に完成した実用システムを維持・改善するには結局、解法と問題領域の両
方についてのノウハウが必要。
専門技術を持ったチームが初期から導入後の維持管理まで担当するのが望ましい。顧客の体制では維持できな
ければ、アウトソーシングになる。
10
Copyright(c) 2006 NTT DATA SEKISUI SYSTEMS Co,ISAC,Inc.
ユーザーとの対話性
(1)分析・設計の段階
条件が複雑で、解の評価も簡単でない「難しい問題」を解くため、ユーザーとの対話性は実用上重要。
制約プログラミングは宣言性の高さと表現が直観的であることが特徴で、説明能力が高い。
問題領域のエキスパートとの対話がスムーズに進むため、プロジェクトの初期段階での意思疎通不
足による設計不良がおきにくい。
人工知能の産業応用で問題になった知識獲得の問題は解消されたわけではなく依然として存在する
が、表現力の豊かさは、分析、モデリングのレベルでは大きな武器になる。
(2)実装の段階
実装上の対話性の確保は別の問題。
解が見つからない場合への対応。
ユーザーが適切なアクションを取れるような情報の提供。
「何故このような解になったのか」のユーザへの説明。
開発者にとっては、デバッグの困難さの問題でもある。
制約プログラミングのみの問題ではなく、複雑な問題解決を行う手法共通の問題。
問題解決能力を全面に押し出すと、ユーザー(特に現場)が反発。業務支援システムという立場の強
調が必要。
ユーザーとの対話性を重んじたシステムが好ましいが、ユーザーの介入の仕方については設計上工
夫が必要。
利用者の知識や習熟度を想定しない設計は事実上困難。
11
Copyright(c) 2006 NTT DATA SEKISUI SYSTEMS Co,ISAC,Inc.
システムの品質
短期間の開発で高品質の結果が得られることは実証済み。
特にカスタムメイドの受託システムでは、全自動・半自動で、人間の専門家と同等かそれ以
上の品質を出せた事例が多数ある。
制約プログラミングは工期（予算）と達成品質の目標のトレードオフに対して柔軟に対
応できる。
どちらかといえば、短期間で初期開発をして、現場の声を聞きながらシステムを改善するやり
方に適している。
最初から厳密に最適化の方向が定義できるなら、品質上他の手法の方がすぐれている可能
性はあるが、現実には困難が大きい。
制約プログラミングは「実用的な」開発手法といえる。
実データによる検証・チューニングは実装方式の検証・品質の向上のために不可欠 。
可能な限りプロトタイピングの段階で実データを用いた検証を実施すべき。
検証環境の整備には、ユーザーの協力が不可欠。
ユーザーに安心感を与える側面も大きい。
12
Copyright(c) 2006 NTT DATA SEKISUI SYSTEMS Co,ISAC,Inc.
他の手法との関係
オブジェクト指向との相性は良い。
自社事例：工程スケジューラ開発のフレームワークとしての制約つきオブジェクトクラスライブラリ
(半導体ラインの工程計画など)
UMLでの制約の扱い。OCL(Object Constraint Language)の提供。[UML02]参照。
パラダイムとしての制約プログラミングは、様々な解法を統合するフレームワークとなる。
cf.[HECS]分散協調制約解消システムHECS(番原、田村、井上、川村、玉置)
線形計画法などのORの手法は代替として常に検討すべき。
制約伝播ベースの制約プログラミングでは、解を探索する必要があり、ヒューリスティクス
の導入は必須。cf.[BARTAK98]
自社事例：Tabuサーチ的な探索制御(生産計画など)
自社事例：local searchを使った解の改良（配送計画など）
参考：標準化推進の現場から
PSLXコンソーシアム(http://www.pslx.org)での生産計画システムインタフェース標準化での議論。
cf.仕様書パート3[PSLX3-06]
「制約」は追加可能だが、標準としては定義されない。
要するに、現場では不可欠だが、多様性が大きすぎて標準にはできない。
実用になるシステムを開発するためには、このギャップを埋める方法論(モデリングの手法・解法)が必要。
実用的な観点から、制約プログラミングは評価されている。
13
Copyright(c) 2006 NTT DATA SEKISUI SYSTEMS Co,ISAC,Inc.
3.事例（１）
屋根パネル積載計画システム[山崎98][山崎01]
Copyright(c) 2006 NTT DATA SEKISUI SYSTEMS Co,ISAC,Inc.
問題・システム化の目的と条件
屋根パネルをトラックに積載する計画。
どのように複数のトラックに分載するか。
どのような順序で積載するか。
2階
トラック
１
6
5
4
トラック
２
3
2
1
1階
10
9
8
7
目的：屋根パネル積載計画を自動的に作成することにより、省力化を図る。
人手での作業では、
熟練が必要。
時間がかかる（最大10～15分／邸）。平均5分として150邸／週の計画を週一度作成するの
で、1人日では作成できない。確認作業も含めると2~3日必要。
ミスが発生する可能性がある。
条件：
基本的に全自動。バッチ処理。
人間は結果の確認のみ。
ＰＣ上で、一回の立案で最大150邸前後の処理ができること。確認も含めて1日で完了。
商品のタイプの増加を考慮する。
順序決定の条件の変化に対応しやすい枠組みが必要。
15
Copyright(c) 2006 NTT DATA SEKISUI SYSTEMS Co,ISAC,Inc.
計画作成の目標
輸送時のパネルの破損を防止し、かつ施工現場の作業が行いやすい順序に積載する。
制約条件の例
軒先の突起は交互に積む。
①
棟違い下側のパネルを上に積む。
天窓・太陽電池などの付属品付きパネルは山の一番上。
長いパネルの下に短いパネルは置けない。
施工作業動線は短いほうがよい。
②
棟違い下優先
トラックの台数はできるだけ少なくしてコストを削減する。
階混載しない＝トラック3台
階混載する＝トラック2台
例）8段積み
2階：10枚
1階：6枚
16
Copyright(c) 2006 NTT DATA SEKISUI SYSTEMS Co,ISAC,Inc.
軒先の突起は交互に
モデル化
直観的なモデル
パネルをオブジェクトとして定義。
制約条件に関わる属性をオブジェクトのプロパティとして定義。
パネルの順序とパレット組(複数のトラックに分載に対応)に対して制約を設定。
制約条件を充足するパネルの積載順序とパレット組を計算する。
トラックの台数・施行時の作業動線の最小化などの複数の選好条件を重み付けして線形
に結合した目的関数を定義し、最適化を行う。
変数の数が少ないため近似的な最適化は可能。
最適化フェーズの打ち切りはタイマーで制御。
17
Copyright(c) 2006 NTT DATA SEKISUI SYSTEMS Co,ISAC,Inc.
3.事例（２）
屋根パネル自動分割システム[山崎01]
Copyright(c) 2006 NTT DATA SEKISUI SYSTEMS Co,ISAC,Inc.
問題・システム化の目的
問題
屋根面をパネルに自動的に分割する。
開口の有無・位置や、隣接屋根面の形状により、分割位置が決まる。
パネルのサイズの上限・下限・標準サイズなどの条件がある。
パネルの枚数・パターンの異なり数など、幾つかの最適化条件がある。
システム化の目的
グリッド単位の自由なプランに対して、基本的に自動的なパネル分割を行うシステムを目指す。
基本的な規則の適用によって多様なプランに対応できるシステムを目指す。
パネル分割方式についての設計支援シミュレーターとして利用できるようにする。
システム設計上の前提
射影平面（屋根伏せ図）上での問題として解く。
分割は、原則として軒線に対して垂直にのみ行う。
隣接する屋根面間の対称性を考慮する。
19
Copyright(c) 2006 NTT DATA SEKISUI SYSTEMS Co,ISAC,Inc.
モデル化①線分分割問題として定式化
１つの屋根面を属性を持った点により構成される１本の射影線分として表現することができ、
屋根パネル配置問題は、この線分の分割の問題として扱うことができる。
分割についての条件として、以下のものが考えられる。
点の属性による分割についての制約条件、優先度などが定義される。
積載・施工・性能などの条件により制約条件、優先度などが定義される。
巨視的なさまざまな最適化条件が与えられるため、問題は、制約最適化問題として定義される。
例）
分割対象の線分
優先分割点
分割禁止点
最大巾
標準巾
積載・ 施工・ 性能等の条件
最小巾
20
Copyright(c) 2006 NTT DATA SEKISUI SYSTEMS Co,ISAC,Inc.
モデル化②制約条件・最適化の条件と方法
制約条件
個別の制約条件については追加・削除を随時行って調整していく。（設計支援シミュレーション）
構法上の条件
開口の条件
輸送条件（道路交通法・積込問題上の制約条件）
施工条件（吊り下げ回数、据え付けの容易性など）
原板サイズ（歩留まり）などの生産条件
断熱性能などの性能条件
最適化
下記の例のような条件につき、優先度づけを行って、最適化の目的関数を構成する。優先度づけは、
評価を行いながら、変更していく。
隣接屋根面での対称性
枚数
パネル形状数
パネル種類数（寸法・属性含む）
標準パネル出現率最大
最適化にあたって、邸全体ではなく、一部の屋根面のみ解の改良を行ないたい場合などに対応する
ために、最適化ステップでは、以下のような割付方法を採用した。
既に得られている解の変更したくない部分のみ、先に結果を領域変数に割り付けてしまう。
通常のように制約を設定する。
通常の残りの部分について、すでに求まっている評価値を上回るという制約を追加した上で探索を行なう。
21
Copyright(c) 2006 NTT DATA SEKISUI SYSTEMS Co,ISAC,Inc.
4.開発プロセスからみた事例の評価
Copyright(c) 2006 NTT DATA SEKISUI SYSTEMS Co,ISAC,Inc.
事例(1)屋根パネル積載計画システム
23
項目
評価
プロトタイピング
ラピッド・プロトタイピング：1ヶ月で作成。
最初から実データを利用した検証。
開発サイクル
典型的なスパイラル開発。3ヶ月以下のサイクルの反復。
保守フェーズを含めると10年間で20サイクル弱。
状況の部分性への対応
最適化フェーズの仕様は、現場での実運用で上がってきた要望ベースで追
加開発。
解の品質
1000邸以上の実データを利用したチューニングを実施。
解品質の向上(最適化目標について10%)、探索効率の向上(約10倍)等の成
果が得られた。
基本的にはシステムが出した解をそのまま現場で利用できるレベルを達成。
全自動システムを実現。
運用：状況の変化への対応
長期(約10年間)にわたる対応。
新製品投入・プログラムの性能向上を繰り返す。
システム導入の効果
初期における短期開発(単年度で初期投資回収)。
その後の変更対応の柔軟性による継続的なC/R効果。
総合評価
制約プログラミングの強みが生かせた例
Copyright(c) 2006 NTT DATA SEKISUI SYSTEMS Co,ISAC,Inc.
事例(2)屋根パネル自動分割システム
24
項目
評価
プロトタイピング
実データ検証を前提にした対話環境つきのプロトタイプ作成(3ヶ月程度)。
検証に威力を発揮(アルバイトを使った検証)。
開発サイクル
モデリング(1ヶ月程度)・プロトタイピング(3ヶ月程度)・実システム(1ヶ月程度：イ
ンタフェースの調整のみ)の3段階開発。
対話的な編集ツールの開発：プロトタイプと実システムと2度開発。エンジンは
基本的に同じものを使用。
状況の部分性への対応
ルールベースに近いモデリング。
「説明原理」としての強みを発揮：屋根パネルの設計者からの知識獲得やコ
ミュニケーションを効率的に行えた。
解の品質
新製品であったため、出現頻度が高いと思われるパターンに基づき、例題を作
成（約300種）。
一括立案実験・評価と切断条件の調整の繰返しによる評価サイクルを実施。
すべての例で設計者の意図を満足していることを検証。
運用：状況の変化への対応
運用開始後にルールの調整を随時実施。
システム導入の効果
制約プログラミングによるモデリングが商品開発上のブレークスルーに。
総合評価
制約プログラミングでなければ出来なかった例
Copyright(c) 2006 NTT DATA SEKISUI SYSTEMS Co,ISAC,Inc.
その他の事例
複雑な工程条件を持った生産ラインの工程スケジューリング(加工系や半導体など)
パッケージベンダへのエンジンのOEM供給。カスタマイズ要望への柔軟な対応。
自社製のスケジューラ向けオブジェクトを備えた制約クラスライブラリ(C++)を用いた受託開発。高
速プロトタイピング。
積み合せ・積み降ろしなどの現場の条件に対応した配送計画
メタヒューリスティクスとの組み合わせ。
要員の勤務条件やスキルなどの特性を考慮した要員計画
パッケージ開発・販売(「快決！シフト君」)。
25
Copyright(c) 2006 NTT DATA SEKISUI SYSTEMS Co,ISAC,Inc.
[参考]事例にみる制約プログラミングの使われ方
他の解法との融合：パラダイムとしての制約プログラミングの実践。
通常のシステム開発環境との調和。
制約プログラミングを「カプセル化」する。
26
アプローチ
適用した問題の例
問題領域に特化したクラスライブラリの中への埋め込み
受託開発用生産スケジューリングクラスライ
ブラリなど
メタヒューリスティクスとの融合(1)：解の改良を行う準備
としての初期解生成に利用
配送ルーティングなど
メタヒューリスティクスとの融合(2)：解改良時の制約違
反のチェッカーとしての利用
要員シフト作成、配送ルーティングなど
演算領域の拡大：上・下限のみを管理する区間型変数
の導入
要員シフト作成など
論理プログラミングベースでない制約解消エンジン（制
約の宣言性は維持）
要員シフト作成など
パッケージ製品での利用
生産スケジューラ・要員シフト作成
Copyright(c) 2006 NTT DATA SEKISUI SYSTEMS Co,ISAC,Inc.
5.まとめと今後の課題
Copyright(c) 2006 NTT DATA SEKISUI SYSTEMS Co,ISAC,Inc.
まとめ
制約プログラミングは開発現場にあった実用的な手法。
生産性が高い。
開発サイクルの短期化に対応可能。
近年主流となっているオブジェクト指向との親和性の高さも魅力的。
プロトタイピング、スパイラル開発との相性が良い。
フィージビリティの確保や性能向上を考えると早期から実データを用いた検証を繰り返すのが望ましい。
ユーザーにとってわかりやすい設計ができる。
問題領域のエキスパートとの対話がスムーズに進むため、プロジェクトの初期段階での意思疎通不足による設計不
良がおきにくい。
柔軟で変化に対する対応力が大きい。
初期開発だけでなく、保守・改良まで考えた場合に、変更に対して頑健な、長期間にわたり使い続けられるシステム
を提供できる。
28
Copyright(c) 2006 NTT DATA SEKISUI SYSTEMS Co,ISAC,Inc.
今後の課題
制約指向の開発方法論の確立。
実用的な技術として存在をアピールし、適用プロジェクトを拡大。
FP法の適用事例の蓄積や分析による精度の向上。
統合パラダイムとしての制約プログラミングの探求
制約伝播ベースの狭義の制約プログラミングと他の手法との組み合わせの推進。(LP, メタヒューリ
スティクス, NN, 進化論的計算 etc.)
29
Copyright(c) 2006 NTT DATA SEKISUI SYSTEMS Co,ISAC,Inc.
参照文献
制約プログラミングについてのより一般的な情報については、http://www.constraint.org/を参照。
[CHIC95] Chamard, Fischer, Guinaudeau, Guillaud, “CHIC Lessons on CLP Methodology”
(1995), http://eclipse.crosscoreop.com/eclipse/reports/CHIC_Methodology.html
[FRON94] Fron, “Programmation par contraintes”, Addison-Wesley France (1994)
[青木93] 青木「オブジェクト指向システム分析設計入門」, ソフトリサーチセンター (1993)
[UML02]ランボー, ヤコブソン, ブーチ, (石塚監訳)「UMLリファレンスマニュアル」, ピアソン・エデュ
ケーション (2002)
[児玉99]児玉「システム開発の見積りのための実践ファンクションポイント法」,日本能率協会マネジメ
ントセンター(1999,改訂版2006)
[BARTAK98] Bartak, “Guide to Constraint Programming” (1998),
http://ktiml.mff.cuni.cz/~bartak/constraints/
[HECS]番原,田村,井上,川村,玉置, 「Javaによる分散協調制約解消システムHECS」(2005),
http://kaminari.istc.kobe-u.ac.jp/hecs/
[PSLXV2-3] PSLXコンソーシアム, 「標準仕様バージョン2 第3部 業務オブジェクトモデル 勧告候
補版」(2006), http://www.pslx.org/
[西原97] 西原「制約充足問題の基礎と展望」, 人工知能学会誌, Vol12, No.3 pp.351—358 (1997)
[橋田94] 橋田「知のエンジニアリング」, ジャストシステム (1994)
[森94] 森, 山崎, モリコン「制約ベース的アプローチによる勤務計画・工程計画立案システムの設計」
1995年度関西経営システム協会懸賞事例集(1995)
[山崎98] 山崎, 森「制約解消系を用いた屋根パネル積込システムの開発」大分統計談話会第17回
(1998)
[山崎01] 山崎「制約プログラミングは計画系システム開発に役立つか」,COM・APS研究部会第4回研
究会 (2001)
30
Copyright(c) 2006 NTT DATA SEKISUI SYSTEMS Co,ISAC,Inc.