ソフトウェア工学 知能情報学部 新田直也.

Presentation on theme: "ソフトウェア工学 知能情報学部 新田直也."— Presentation transcript:

1 ソフトウェア工学 知能情報学部 新田直也

2 ソフトウェア工学の現在 ソフトウェア工学の議論は，いつでもプロセス（開発工程）かプロダクト（成果物）が中心． プロセス： プロダクト：
アジャイル開発 ← ハッカー モデル駆動型アーキテクチャ（MDA） ← IBM ソフトウェアファクトリ ← マイクロソフト プロダクト： UML デザインパターン フレームワーク 可変性分析，マルチパラダイムデザイン アスペクト指向，サブジェクト指向 サービス指向アーキテクチャ（SOA）

3 プロセスにおける論点 基本的にパラダイムはオブジェクト指向から進歩していない． 論点は，軽量級か重量級か?
アジャイル： 軽量級（人間性を重視） モデル駆動型アーキテクチャ，ソフトウェアファクトリ： 重量級（工学性，機械性を重視） 根本には，ソフトウェア開発は技芸か?数理か?という議論がある． 個人的な立場： 基本的には技芸だが，未知の数理によって開発がもっと楽になるのでは?

4 モデル駆動型アーキテクチャ UMLはOSや言語に依存しない． UMLを高級プログラミング言語とみなせないか? 個人的な批判：
OMG（Object Management Group）主導で進められている． Eclipseなどでも対応しつつある． 個人的な批判： 図で書くよりプログラミングする方が早い． 図だけで細かい処理を記述するのは困難． 結局，ウォーターフォールの延長線上にある．

5 統一プロセス（Unified Process）
UMLは記法の統一のみであった． UMLのスリーアミーゴがプロセスの統一も目指した． 3つの特徴． ユースケース駆動： ユースケース図を基本に開発を進める． アーキテクチャ中心： アーキテクチャ（システムの全体構造）を洗練させていく． 繰り返し型開発： 基本的にスパイラルモデルと同様．ただし，各繰り返しは方向付け，推敲，構築，移行というフェーズによって構成される．

6 プロダクトにおける論点 結局，パラダイムはオブジェクト指向から進歩していない． この先，どこへ向かうのか? UML デザインパターン
フレームワーク この先，どこへ向かうのか? オブジェクト指向によってプログラムの設計がより強く意識されるようになった． 設計にパターンしか見出せていないということは，結局，設計に関する理論がまだ未完成であるということ． 可変性分析，マルチパラダイムデザインが新しい方向性．

7 フレームワーク アプリケーション間で共有されるソフトウェアの骨組みに相当するソースコード． オブジェクト指向技術に基づく．
社内の複数アプリケーション間で共有． 世界中で共有．（フレームワーク単体で流通．） オブジェクト指向技術に基づく． 親クラス（抽象クラス）の集合． 多相性によってフレームワーク側からアプリケーション側が呼び出される（制御の反転）． ハリウッドの原則：「俺に電話するな．必要ならこちらから電話する．」 アプリケーション ライブラリ アプリケーション フレームワーク

8 フレームワークの長所と問題点 長所： 問題点： ライブラリより再利用の単位が大きい． 実装だけでなく設計も再利用することができる．
メインループを再利用することができる． 問題点： 使い方が難しい． 理解するのに時間がかかる． 開発できるアプリケーションが制限される． 場合によっては実装工程終盤でフレームワークが使えないことが判明し，プロジェクトが進まなくなってしまうこともあり得る．

9 サービス指向アーキテクチャ ソフトウェア部品や機能（サービス）をネットワーク上にインタフェースと共に公開．
サービス間の連携によってシステムを構築する． Webサービス インタフェース記述： WSDL 遠隔呼出し（バインド）： SOAP 分散オブジェクトシステムとほぼ同義． 呼出し側の記述が簡潔になったことが特長．

10 アスペクト指向 オブジェクト指向を補完するパラダイム． 主にIBMが主導．
オブジェクト指向におけるクラス階層は単一の視点から見たものに過ぎない．その視点でモデル化できない処理は複数クラスに分散．（横断的関心事） たとえばログ出力処理は，ほとんどすべてのクラスに散らばる． 横断的関心事をアスペクトとして抜き出す． アスペクトはコンパイル時または実行時にクラスに織り込まれる．（ウィービング）

11 まとめ まさに現在進行形なのでまとめることは不可能． ただし，プロセスの観点とプロダクトの観点は重要．
ソフトウェア工学が面白い時代? （過渡期?） 混乱しているということは，裏を返せば，新しいパラダイムの誕生前夜なのかもしれない．

12 ソフトウェア工学のまとめ ソフトウェア工学： ソフトウェアの開発，運用，保守に対する，系統的で統制され定量化可能な方法．すなわちソフトウェアへの工学の適用． ソフトウェア工学は未だ確立していない． 銀の弾丸などない（人月の神話，F.P.ブルックス,Jr.） → 一歩一歩ゆっくりと進歩していくしかない． ソフトウェアの本質： 複雑性 同調性 可変性 不可視性

13 まとめのまとめ 結局，特効薬（銀の弾丸）はまだ存在しない．
技術の地道な積み重ねによってのみ発展する? → 新しい技術をチェックしておくこと． ただし，ソフトウェア工学分野には使えない技術も多いので注意が必要． 「ここが明るくて探しやすいからですよ。」 後は，実務経験を積むこと． 失敗 苦労