Transcript プログラム再構成に関する 特許申請について

ソフトウェア工学
知能情報学部
新田直也
ソフトウェア工学の現在


ソフトウェア工学の議論は，いつでもプロセス（開発工程）か
プロダクト（成果物）が中心．
プロセス：




アジャイル開発
モデル駆動型アーキテクチャ（MDA）
ソフトウェアファクトリ
プロダクト：






UML
デザインパターン
フレームワーク
可変性分析，マルチパラダイムデザイン
アスペクト指向，サブジェクト指向
サービス指向アーキテクチャ（SOA）
← ハッカー
← IBM
← マイクロソフト
プロセスにおける論点
基本的にパラダイムはオブジェクト指向から進歩し
ていない．
 論点は，軽量級か重量級か?




アジャイル： 軽量級（人間性を重視）
モデル駆動型アーキテクチャ，ソフトウェアファクトリ：
重量級（工学性，機械性を重視）
根本には，ソフトウェア開発は技芸か?数理か?とい
う議論がある．

個人的な立場：
基本的には技芸だが，未知の数理によって開発がもっと
楽になるのでは?
モデル駆動型アーキテクチャ
UMLはOSや言語に依存しない．
 UMLを高級プログラミング言語とみなせないか?





UML（特にクラス図）から，プラットフォームに合ったプロ
グラムを自動導出する試み．
OMG（Object Management Group）主導で進められ
ている．
Eclipseなどでも対応しつつある．
個人的な批判：



図で書くよりプログラミングする方が早い．
図だけで細かい処理を記述するのは困難．
結局，ウォーターフォールの延長線上にある．
統一プロセス（Unified Process）
UMLは記法の統一のみであった．
 UMLのスリーアミーゴがプロセスの統一も目指した．
 3つの特徴．




ユースケース駆動：
ユースケース図を基本に開発を進める．
アーキテクチャ中心：
アーキテクチャ（システムの全体構造）を洗練させていく．
繰り返し型開発：
基本的にスパイラルモデルと同様．ただし，各繰り返しは
方向付け，推敲，構築，移行というフェーズによって構成
される．
プロダクトにおける論点

結局，パラダイムはオブジェクト指向から進歩してい
ない．




UML
デザインパターン
フレームワーク
この先，どこへ向かうのか?



オブジェクト指向によってプログラムの設計がより強く意
識されるようになった．
設計にパターンしか見出せていないということは，結局，
設計に関する理論がまだ未完成であるということ．
可変性分析，マルチパラダイムデザインが新しい方向性．
フレームワーク

アプリケーション間で共有されるソフトウェアの骨組
みに相当するソースコード．



社内の複数アプリケーション間で共有．
世界中で共有．（フレームワーク単体で流通．）
オブジェクト指向技術に基づく．



親クラス（抽象クラス）の集合．
多相性によってフレームワーク側からアプリケーション側
が呼び出される（制御の反転）．
ハリウッドの原則：「俺に電話するな．必要ならこちらから
電話する．」
アプリケーション
ライブラリ
アプリケーション
フレームワーク
フレームワークの長所と問題点

長所：




ライブラリより再利用の単位が大きい．
実装だけでなく設計も再利用することができる．
メインループを再利用することができる．
問題点：



使い方が難しい．
理解するのに時間がかかる．
開発できるアプリケーションが制限される．

場合によっては実装工程終盤でフレームワークが使えないことが
判明し，プロジェクトが進まなくなってしまうこともあり得る．
サービス指向アーキテクチャ
ソフトウェア部品や機能（サービス）をネットワーク上
にインタフェースと共に公開．
 サービス間の連携によってシステムを構築する．
 Webサービス




インタフェース記述： WSDL
遠隔呼出し（バインド）： SOAP
分散オブジェクトシステムとほぼ同義．

呼出し側の記述が簡潔になったことが特長．
アスペクト指向
オブジェクト指向を補完するパラダイム．
 主にIBMが主導．
 オブジェクト指向におけるクラス階層は単一の視点
から見たものに過ぎない．その視点でモデル化でき
ない処理は複数クラスに分散．（横断的関心事）


たとえばログ出力処理は，ほとんどすべてのクラスに散ら
ばる．
横断的関心事をアスペクトとして抜き出す．
 アスペクトはコンパイル時または実行時にクラスに
織り込まれる．（ウィービング）

まとめ
まさに現在進行形なのでまとめることは不可能．
 ただし，プロセスの観点とプロダクトの観点は重要．
 ソフトウェア工学が面白い時代? （過渡期?）
 混乱しているということは，裏を返せば，新しいパラ
ダイムの誕生前夜なのかもしれない．

ソフトウェア工学のまとめ

ソフトウェア工学：
ソフトウェアの開発，運用，保守に対する，系統的で統制さ
れ定量化可能な方法．すなわちソフトウェアへの工学の適用．

ソフトウェア工学は未だ確立していない．


銀の弾丸などない（人月の神話，F.P.ブルックス,Jr.）
→ 一歩一歩ゆっくりと進歩していくしかない．
ソフトウェアの本質：




複雑性
同調性
可変性
不可視性
まとめのまとめ
結局，特効薬（銀の弾丸）はまだ存在しない．
 技術の地道な積み重ねによってのみ発展する?
→ 新しい技術をチェックしておくこと．
 ただし，ソフトウェア工学分野には使えない技術も多
いので注意が必要．
「ここが明るくて探しやすいからですよ。」
 後は，実務経験を積むこと．



失敗
苦労