[jfriends-ml 11463] Re: 俗流オブジェ クト指向 (Re: UML)

[TAKAHASHI Toru <torutk@xxxxxxxxxxxx>]

高橋（徹）です。

   "Takeshi Ito <linus@xxxxxxxxxxxx>"さんは書きました：
> > 一方、ビジネスモデリングではオブジェクト指向よりもDAOが適用される
> > ことも多いのではないかと思います。
> 
> 恐れ入ります。DAOとは初めて聞きましたが、どういう
> ものなのでしょうか？
DOA(Data Oriented Approach)の誤記です。大変失礼しました。

> そうですよね。むずかしいですよね。しかし、少なくとも
> ・内部の動きにまで立ち入らない。　
> ・アクターとの情報のやりとりがなければならない。
> 　by オージス総研インターンシップの経験
> は基本だと思います。結構、システムの中身のほうまで楕円を
> 書いてしまうことはあるようです。
実際のシステム開発において、RFPレベルでもシステム内部の記述が
含まれていることもあり、どこまで記述するか悩みが尽きない部分です。
特に、既存システムの置き換えの場合に顕著です。

> それでも、粒度は難しいですよね。他のユースケースとの
> バランスなどを吟味しないと理解がむずかしくなりますし。
> 
> ユースケース専門の書物を読んだことがないので、
> そのあたりに関して、記述されている文献をご存知の方
> がいらっしゃったら、教えていただきたいです。
「ユースケース実践ガイド -効果的なユースケースの書き方」
（Alisteir Cockburn著、翔泳社）
がよく引き合いに出されているようです。

ここ数ヶ月の月刊ジャバワールド誌において、浅海さんの連載記事に
ユースケース分析を扱っています。いくつか文献を紹介・参照していた
ので、参考になるかと思います。
＃そういえば簿記の例も記事にありました。

> それでも、規模の大きな案件ですと、RFPの枚数がかなりに
> なりますので、どこを作って欲しいのか、
> 誰のためのどういう機能がほしいのか、などの現状把握に
> 結構時間をとってしまい、かつ、RFPの書類ベースで
> 議論しているとメンバー内で現状の認識にずれがあったりして、
> それを修正する議論に時間をとられて、提案部分の検討議論
> に時間を割く時間が少ないというのが私の少ない経験での
> 印象です。
> 
> ですので、そうならないために、ほんとにお絵かき程度の
> UML図（ユースケース図、アクティビティ図）でもあると
> 本題の議論に時間を注ぐ時間が増すと考えておりますし、
> 効果があったと認識しております。
コミュニケーションのためにという点はそうですね。

提案書のような形にUMLをどう反映させるかというと難しいなと
現状では思っています。そのあたり世の中どう整合しているのか
興味があります。
業種によって異なるかもしれませんが、今まで経験した提案書では
システムの実現内容にまで踏み込んだ記述をしているので、分析を
通り越してシステム設計からソフトウェアのアーキテクチャ設計まで
を行った結果のようなものまで範囲に入ってしまいます。
「非機能要求」に含まれるシステム性能、計算機・ネットワークの
スペック、異常系処理（冗長構成やバックアップ等）、システム監視系
の機能なども含まれます。
UMLはこれら非機能要求をある意味切り捨てることによって成り立って
いるとも思います。実際作ってみないと分からないことを提案書に
盛り込む結果となってしまい、歪んでいるのかもしれませんが・・・。


TAKAHASHI, Toru