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

昨日、

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


で書いた話の続き。

昨日は、

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

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



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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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



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


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

について