UMLモデルのみでソフトウェアが作れる時代がくるとは思わない。これまでの成功・失敗から学んだこと、これからの方向性を、設計、計画にラフで適切に抽象化してこめて記録する。素早く共有、実践し、軌道修正しながら開発をすすめる。
そのために注意する部分、あえて切り捨てる部分があるのではないか。
1章だけでもUMLの活用方法、つきあい方に関する深い洞察が得られるだろう。
P6
さて、その上で私の立場をはっきりさせておく必要があります。ほとんど必ずと
いってよいほど、私はUMLをスケッチとして使用します。UMLによるスケッチは、
フォワードエンジニアリングとリバースエンジニアリングのどちらにも使え、
概念的観念とソフトウェア的観点のどちらにとっても便利だと思います。
私は細部までフォワードエンジニアリングされた設計図面を支持しません。これを
うまく扱うのは非常に難しく、開発作業の遅れにつながると思っています。
サブシステムのインターフェイスレベルの設計図面を作成することは合理的ですが、
それでも開発者がこれらのインターフェイス間のやり取りを実装するのに合わせて、
インターフェイスが変更されることを予想しておく必要があります。
ブログラミング言語としてのUMLというのは良い考えだと思いますが、うまく
使われるかどうかは疑問です。ほとんどのブログラミング業務において、テキスト
形態よりもグラフィック形態のほうが生産性が高いとは確信を持って言えません。
たとえそうであっても、その言語が幅広く受け入れられるのは非常に困難です。
P67
全体と部分を表すが、実装上の意味はない。Jim Rumbough 曰く、集約はモデリングの気休め薬。
- 感想投稿日 : 2015年11月15日
- 読了日 : 2008年12月17日
- 本棚登録日 : 2011年12月10日
みんなの感想をみる