ソフトウェア工学1221

ソフトウェア工学
理工学部
情報システム工学科
新田直也
ソフトウェア工学の現在


ソフトウェア工学の議論は，いつでもプロセス（開発工程）か
プロダクト（成果物）が中心．
プロセス：




アジャイル開発
モデル駆動型アーキテクチャ（MDA）
ソフトウェアファクトリ
プロダクト：






UML
デザインパターン
フレームワーク
可変性分析，マルチパラダイムデザイン
アスペクト指向，サブジェクト指向
サービス指向アーキテクチャ（SOA）
← ハッカー
← IBM
← マイクロソフト
プロセスにおける論点
基本的にパラダイムはオブジェクト指向から進歩し
ていない．
 論点は，軽量級か重量級か?




アジャイル：軽量級（人間性を重視）
モデル駆動型アーキテクチャ，ソフトウェアファクトリ：
重量級（工学性，機械性を重視）
根本には，ソフトウェア開発は技芸か?数理か?とい
う議論がある．

個人的な立場：
基本的には技芸だが，未知の数理によって開発がもっと
楽になるのでは?
モデル駆動型アーキテクチャ
UMLはOSや言語に依存しない．
 UMLを高級プログラミング言語とみなせないか?





UML（特にクラス図）から，プラットフォームに合ったプロ
グラムを自動導出する試み．
OMG（Object Management Group）主導で進められ
ている．
Eclipseなどでも対応しつつある．
個人的な批判：



図で書くよりプログラミングする方が早い．
図だけで細かい処理を記述するのは困難．
結局，ウォーターフォールの延長線上にある．
ソフトウェアファクトリ


マイクロソフトがソフトウェア工学に参戦した．

OOPSLA2004で発表．

http://www.atmarkit.co.jp/fdotnet/softfactory/softfactory01/so
ftfactory01_01.html
ソフトウェア開発の工業化を目指すもの．




OSでは商売が続けられないと悟った?
ソフトウェアファミリという視点．
ひとことで言えば，さまざまな方法論の寄せ集め．



実は日本のソフトウェア開発をモデルにしている．
アプリケーションドメインに応じた方法論を選ぶための基盤構築を目
指す．
フィーチャモデル，サブジェクト指向，DSL…
個人的な批判：節操がない? やはりウォーターフォール的?
プロダクトにおける論点

結局，パラダイムはオブジェクト指向から進歩してい
ない．




UML
デザインパターン
フレームワーク
この先，どこへ向かうのか?



オブジェクト指向によってプログラムの設計がより強く意
識されるようになった．
設計にパターンしか見出せていないということは，結局，
設計に関する理論がまだ未完成であるということ．
可変性分析，マルチパラダイムデザインが新しい方向性．
フレームワーク

アプリケーション間で共有されるソフトウェアの骨組みに相当
するソースコード．




社内のアプリケーション間．
世界中．
もちろんオブジェクト指向（多相性）に基づく．
ハリウッドの原則（制御の反転）：
「俺に電話するな．必要ならこちらから電話する．」
アプリケーション

ライブラリ
アプリケーション
いくつかの問題点：


理解するのに時間がかかる．
あらゆるアプリケーションに応用できるわけではない．
フレームワーク
サービス指向アーキテクチャ
ソフトウェア部品や機能（サービス）をネットワーク上
にインタフェースと共に公開．
 サービス間の連携によってシステムを構築する．
 Webサービス




インタフェース記述： WSDL
遠隔呼出し（バインド）： SOAP
分散オブジェクトシステムとほぼ同義．

呼出し側の記述が簡潔になったことが特長．
可変性分析

ソフトウェアを変化し易い部分（ホットスポット）と変化しにく
い部分（コールドスポット）に分ける．


W.Preeによる．
デザインパターンやフレームワークの基礎づけを目指す．
フレームワーク側
（コールドスポット）
アプリケーション側
（ホットスポット）
マルチパラダイムデザイン

可変性分析をさらに発展させた．

J.Coplienによる．
ファミリという概念の導入．
 可変性分析と共通性分析の双方の分析が必要．
 可変性を実現する実装機構は，クラスの継承構造
だけではない．
（C++のテンプレート，条件コンパイルなど）
 可変性に応じた実装機構を選ぶべき．


アプリケーションドメインの可変性とソリューションドメイン
の可変性を適合させること．
アスペクト指向
オブジェクト指向を補完するパラダイム．
 主にIBMが主導．
 オブジェクト指向におけるクラス階層は単一の視点
から見たものに過ぎない．その視点でモデル化でき
ない処理は複数クラスに分散．（横断的関心事）


たとえばログ出力処理は，ほとんどすべてのクラスに散ら
ばる．
横断的関心事をアスペクトとして抜き出す．
 アスペクトはコンパイル時または実行時にクラスに
織り込まれる．（ウィービング）

サブジェクト指向
ユースケース図とクラス図の関連付け．
 横断的関心事の1つの見方．
 主にマイクロソフトが主導．
 ユースケース図に登場するクラス（オブジェクト）は
役割を持つ．
 クラス（メソッド）を役割ごとに分割する．

まとめ
まさに現在進行形なのでまとめることは不可能．
 ただし，プロセスの観点とプロダクトの観点は重要．
 ソフトウェア工学が面白い時代? （過渡期?）
 混乱しているということは，裏を返せば，新しいパラ
ダイムの誕生前夜なのかもしれない．


Download Report