はたして非機能要求はUMLで設計できないか。 その1 <アスペクト指向の改良についての提案序章>




第9回 ソフトウェアパターン勉強会
で次回のプレゼンテーターの方がポロっと「非機能要求」はUMLではできないとおっしゃっていましたが、それってホント?
開発の現場ではいわゆる「伝票」だとか「消費税」のような業務的なものとは別の非機能要求に関する設計開発作業は結構大きいものです。
業務要件を実現するための枠組みとしてフレームワーク開発をやってきた訳ですが、実績として非機能要求こそUMLをつかった設計に威力を発揮できる領域であるように感じます。
それほどUMLは、というよりオブジェクト指向分析手法は強力であると思っています。

まず非機能要求とはなにかですが良く言われるのは、拡張性、再利用性、パフォーマンス、信頼性、等です。
さらに業務側(機能要求側)開発者のスキルレベルやオブジェクト指向スキルレベルにあわせるなんていう要求もあります。
たいていはマシンの構成や、ミドルウェアの選定などがその対象となるわけですが、現実としてこのことは設計→機能としてはどう現れるのでしょうか。

・拡張性
       IOCコンテナ
       ファクトリー系パターンの標準化
・再利用性
       コンポーネントフレームワーク
       インターフェース標準化
・パフォーマンス
       パフォーマンス測定サポート
       システム動作モードサポート
・信頼性
       ログ出力機能のフレームワーク化
       デバッグ機能サポート
       エラー処理標準化サポート
       運用監視
・業務実装者スキル対応
       標準APIの機能制限

...

超ざっくり書いてます。
あんまり書くとノウハウ流出になっちゃうんで。(笑)

みてみると「非機能」とはいいながらそれを実現あるいはサポートするための、なんらかの機能実装が必要になるわけです。
つまり「非機能要求」の問題領域はシステム自体になるわけです。

問題領域が明確になればあとは、通常のOO分析手法が使えます。
構造分析に登場するオブジェクトは「ログ」であったり「エラー」であったりする訳です。
システム自体を問題領域とした、オブジェクト指向分析、設計は非常に有効に機能します。
特に、それらをサポートするアプリケーションフレームワークを設計するときには顕著です。

要件がアプリケーションフレームワークであれば、問題領域は業務アプリケーション実装です。
決して業務アプリケーション自体ではありません。
つまり業務クラス、メソッドなどがその分析対象になります。

その2へつづく

Posted: 木 - 10月 7, 2004 at 08:45 PM      
    |


©