PressmanのSoftware Engineeringを超訳ななめ読み その７－モデリング

みんなから、無慈悲な稲妻を受けないために、
大事そうなところを、超訳＆ななめ読みしている

PressmanのSoftware Engineeringを超訳ななめ読みする

を久々に・・

いままでで、５章が終わっているので、今日は６章

---

■６章要求モデリング：シナリオ、情報、分析クラス
６．１　要求分析
　以下のタイプのモデリングが挙がっている

　　・シナリオベースモデル
　　・データモデル
　　・クラス指向モデル
　　・フロー指向モデル
　　・振る舞いモデル

６．１．１　目的と哲学の全容
　要求モデルは、「Ｗｈａｔ」に主にフォーカスを置く。「Ｈｏｗ」ではない。
　とおなじみのことが書かれた後に、３つの主な目的があるとしている
　（１）顧客の要求が何か、記述する
　（２）ソフトウェア設計を作るに当たっての基礎を確立する
　（３）ソフトウェアができた際、妥当性が確認できる要求の定義
　で、要求モデル（分析モデル）とシステム記述、設計モデルが重なるよ！
　ということを、図６．１で示している

６．１．２　分析ルール
　あ～６個載ってる。省略！

６．１．３　ドメイン分析

６．１．４　要求モデリングアプローチ

　６．３に、要求モデルと、各種の図の関係がある。

　　・シナリオベースモデル
　　　　　ユースケース
　　　　　ユーザーストーリー
　　・クラスモデル
　　　　　クラス図
　　　　　コラボレーション図
　　・フローモデル
　　　　　ＤＦＤ
　　　　　データモデル
　　・振る舞いモデル
　　　　　状態遷移図
　　　　　シーケンス図

　なるほど・・・

---

■６．２　シナリオベースモデリング

　６．２．１　準備段階のユースケースを作る
　　　カメラがインターネットとつながって・・・うん？
　　　とにかくＡＣＳ－ＤＣＶというのを例に、ユースケースを作っている

　６．２．２　準備段階のユースケースを洗練する

　６．２．３　フォーマルなユースケースを書く
　　　ユースケース記述に基づいて書く
　　　図６．４　にユースケース図を遣って書いている

---

■６．３　ユースケースを支援するＵＭＬモデル

６．３．１　アクティビティ図の開発
　スイムレーン１つ分のアクティビティ図

６．３．２　スイムレーンダイアグラム
　スイムレーンを並べて図を書く、ふつうのアクティビティ図

---

■６．４　データモデリングの概念

６．４．１　データオブジェクト

６．４．２　データの属性

Ｉｎｆｏ：データオブジェクトとオブジェクト指向のクラス
　　－　それらは、同じもの？

６．４．３　リレーションシップ

Ｉｎｆｏ：ＥＲ図

ソフトウェアツール：データモデリング
　目的
　メカニック
　代表的ツール
　　ERWin
　　ER/Studio
　　Oracle Designer
　　Visible Analyst

---

■クラスベースのモデリング

６．５．１　分析クラスの認識

６．５．２　属性の仕様化

６．５．３　操作の定義

　ここで６．９にクラス図

６．５．４　クラス-責務-コラボレータ（ＣＲＣ）モデリング
　図６．１１にＣＲＣカードの例がある

６．５．５　アソシエーションと依存

６．５．６　分析パッケージ
　パッケージの話

---

そのあと、サマリーがあって・・・という各章、同じ構成。

美人過ぎるＣＤＯ（チーフ・デジタル・オフィサー）に会える！申し込み？？

　美人過ぎるニューヨークのＣＤＯ（チーフ・デジタル・オフィサー）、レイチェルさん（２７歳）と会える！申し込み・・・らしい

NY市から1週間のNY旅行とあのレイチェルさんと会える権利のプレゼント企画
http://nyliberty.exblog.jp/20297271/

によると(以下太字は上記サイトより引用）


ここで1つ、「一度で良いから、レイチェルさんにお会いしてみたいなぁ・・・」と思っている、アメリカまたはイギリスにお住まいの皆さんにグッド・ニュースがあります。5/20-23にニューヨークで開催される「インターネット・ウィーク」（2013 Internet Week New York）にあわせて、ニューヨーク市からの超ビック・プレゼントが発表されました。

その内容は、ニューヨークまでの旅費と5/20-26まで1週間の宿泊費、「インターネット・ウィーク」のオール・アクセス・パス、IT企業ツアーやアフターパーティ等のほか、なんと、レイチェルさんとの一対一のミーティングも!!!　


申し込み先のサイトは、上記のサイトにいって、この引用部分のすぐあとを見るとわかる。

Astah*で、上流から、下流まで、トレーサビリティをもって開発する方法（３）

昨日、

Astah*で、上流から、下流まで、トレーサビリティをもって開発する方法（２）
http://blog.goo.ne.jp/xmldtp/e/5feafa838af667987ed230e9ef5688bc


で書いた話の続き。

昨日は、

（５）アクティビティ図の入出力に対する部分がＶｉｅｗとなり、
　　　クラス図（ＥＲ図に相当する）ところが、モデル（ＤＡＯ）になり
　　　アクティビティは、Ｖｉｅｗを受ける部分にあたるので、コントローラーとなる。

をやって、
・「年月日」といった、型の話は出てこなかった。
・「集約」でも「コンポジション」でもどっちでもいい
という話が残っていた。今日は、まずそれを片付ける。

---

■型とか、ブロックとかについて

　クラス図でＶｉｅｗを書いた。
　しかし、Ｖｉｅｗの一部分がまとまりのときがある。
　たとえば、
　　　Ｖｉｅｗで何箇所も出てくる、年月日のような型
　　　Ｖｉｅｗの中の項目の値として出てくる、男女のような決まった値
　　　Ｖｉｅｗの中の一部分(の繰り返し）として出てくる、受注明細のような部分
　こういったのは、部品として、まとめておく。

今回だと、問４は、男女なので、こんなふうに書ける

男女だと、ステレオタイプは本来、enumなんだろうけど、上記のモノを、
全部まとめて扱いたいので、こんなふうにしている。

受注明細は、こんなかんじ

受注と受注明細のように、部分になっているものは、線をつなぐ
（でないとわからないから）
型の場合は、クラスを切って、型のところの名前をセット
（型名でつながりはわかるから）

「商品」は、部品になるんじゃないの・・・
という至極当然な意見があると思う。
部品にしてもいい。でも、この段階でやらなくてもいい。
あとで、正規化するときにすればよい。

これらの部品(ステレオタイプparts）は、
　　モデルでは、テーブルとして
　　Viewでは、１つの部品に
なる「可能性がある」（ならないこともある）

---

■「集約」でも「コンポジション」でもどっちでもいい

　画面に分割したとき、元の画面と、分割した画面は、

「集約」でも「コンポジション」でもどっちでもいい

と書いた。その心は、上に書いた、「商品」の分割と同じ。
この段階で、コンポジションにしてしまっても、後でまとめて
考えても良い。

本来、集約とコンポジションの違いは、私の理解が正しければ、

　　集約は親子の生存の制限はない
　　コンポジションは、生存が一致

ということは、たとえば、共通画面みたいなのが出てきた場合、
コンポジションではない。他のところでつかわれるかもしれないから。

画面分割中に、この画面は、このように分割され、ここでしか使われない
と判っていれば、コンポジションにできるかもしれないが、
そうでない場合、集約でかまわない。
全部画面を書き出してから考えれば良いし、そもそも、コンポジションか
集約かで、開発が変わることもない。
なので、集約で書いてかまわない。この前の例もそうしている。

---

ということで、疑問点は書いた。
次回は、


（４）その後、ＭＶＣアーキテクチャを採用したとすると、
　　　なんかのフレームワークを決めて、

について

ソーシャルゲーム、開発会社の黄昏

Klabの話を中心とした、ソーシャルゲームの採算悪化の問題。
開発スピードが遅れ・・・というのは、既視感が・・・
ゲーム業界と同じ構造？

ソーシャルゲーム、開発会社の黄昏
http://zasshi.news.yahoo.co.jp/article?a=20130417-00013690-toyo-bus_all