ソフトウェア開発メモ

日々のソフトウェア設計、実装で考えている、気づいた事を書いています。それが真実か否かは保証しません。悪しからず。

オブジェクト指向と機能指向、オブジェクト指向開発で異彩を放つロバストネス図について

 まず、私は業務系システムの専門家でも、百戦錬磨のオブジェクト指向開発で専門家でもないのを断っておきます。今、ICONIXプロセスについて学んでいます。他にも色々勉強しているけど。

他の方もAmazonのレビューやBlog等で触れているように、アジャイル系のわりにといったら変だけど、このプロセスは軽量な割に成果物とその役割がしっかりしている。隠れロバストネス図愛好家も多い。元々、GUIアプリケーションの開発を前提にしたプロセスで、素早く開発/公開してから最大数年の間エンハンスが必要なスマホアプリの開発にも有用だと思う。

 ただ、 勉強して行く中でロバストネス図が理解できなかった。ICONIXで主張しているように単にユースケースを絵に表したものに過ぎないという事は分かるけど。各クラス間の線の結びつきの関係と→の向きが特に腹に落ちない。なんなんだろう。この図はという感じで、で、責務と機能の違い、データ中心アプローチとオブジェクト指向分析、構造化分析/設計でいうデータフロー図、ユースケースの存在意義を色々調べて気がついた。

ロバストネス図はオブジェクト指向開発で機能面にフォーカスするためのもの

よく言われているとおり、オブジェクト指向システムが得意とするシステムにデータフロー図は余りなじまないと思う。どっちかというとバッチ処理向きのシステム図。後、オブジェクト指向設計はどのクラスにどの操作を割り当てるかというのが出てくるので、データフロー図というのは他の図と不整合を起こしやすい。

 とはいっても、ソフトウェアである以上、機能を検討する事は重要。やはり、機能面やデータフロー、イベントフローが色々検討したいという事でデータフロー図をオブジェクト指向、とりわけイベントドリブンなシステムで使えるようにリニューアルしたものかなと思う。

 OOSEやRUPではコントローラはクラスだけど、ICONIXは機能として割り当てている。コントローラはプラットホームやアプリの性質等で設計の要素が強く入りすぎるので機能として書いたのだろう。この時点でクラスとして安易に割り当てるのはおかしい。シーケンス設計の段階でバウンダリーメソッドになるか、ドメインモデルのメソッドになるか、独立したコントロールオブジェクトか決めようと。

その副産物としてソフトウェアを知らない人でもある程度分かり、レビューや議論ができるようになった。画面系クラスとエンティティ系クラスのみが出現して、制御系クラスのようなテクニカルなクラスがこの時点では出てこないし。予備設計とか予備分析のための図というはそういう位置づけなんだろう。