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

[Takeshi Ito <linus@xxxxxxxxxxxx>]

伊藤です。

TAKAHASHI Toru wrote:

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

DOAですね。名前ぐらいしかしらなくて。最近、上手さんに
DOA+コンソーシアムとその入門者向け資料のありかを
教えていただいたので、もうちょっとよんでみたいと思います。
＃DOAでもビジネスモデリングするとはしりませんでした。

ERモデルベース＋DFDかなとか勝手に思ってました。勉強します。

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

そうなのですか。

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

そのようですね。やっぱりこれを読むことにします。
＃でもちょっとお高い。

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

ポインタありがとうございます。たまたま寮の古本
コーナーに今年のJava World全部捨ててあったんで、
読めます！

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

提案書にUMLの内容をいれるのは現状ではむずかしそうです。
お客様が読み方しらないと通じないと思われます。
もちろん、UMLの存在はしってて、使ってるんだなと
いうのを知らせるのに意味がありそうなら入れるのも
可ですが。

うちでは、システムの構造やフローは、
その場限りの独自絵で書いてます。採用の可否とは
ダイレクトにむすびつくことはないですが、入れていると
ちゃんとうちの要件をよく勉強しているなということで
アピールになるのだそうです。

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

あー、私もそう思いました。

> 実際作ってみないと分からないことを提案書に
> 盛り込む結果となってしまい、歪んでいるのかもしれませんが・・・。

私も経験はすくないですが、そのように感じております。

大変、勉強になりました。ありがとうございます。

--
Takeshi Ito     linus@xxxxxxxxxxxx