回答編集履歴
1
#6 に返事
test
CHANGED
|
@@ -1,3 +1,12 @@
|
|
|
1
1
|
定義とか人次第なので適宜読み変えればいいのですが、ユースケース、シナリオは通常、オブジェクト指向だと分析に分類され、設計には入りません。それらは設計の入力に該当します。
|
|
2
2
|
https://ja.wikipedia.org/wiki/%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E6%8C%87%E5%90%91%E5%88%86%E6%9E%90%E8%A8%AD%E8%A8%88
|
|
3
3
|
質問者さんの想定次第ですね。
|
|
4
|
+
|
|
5
|
+
#6
|
|
6
|
+
> 名詞も動詞も目的語もあるはず。すると、制約も分析だとすれば、私の言いたいことは「シーケンス図からクラスの振る舞いを特定せよ」だけになります。
|
|
7
|
+
分析にもクラス図は使用できます。それらは概念モデルとして対象の振る舞いを規定しているだけになり、設計上のクラス(一応実装と1:1に対応するものとします)に対する制約には必ずしもなりません。もちろんこういうのはプロセス(工程)として何を作るか、どういうものとするか、みたいな話に依存するので、プロジェクトの規定に依存します。ようは分析アウトプットはあまり正確な記載のない要件定義から、明確な仕様を規定し、要求者(顧客)と合意するための資料、と個人的には考えています。
|
|
8
|
+
設計に近い形での仕様合意ができることが利点です。
|
|
9
|
+
|
|
10
|
+
設計上のシーケンス図などの動的な振る舞いを表すモデルは、設計上の対応するクラス図などの静的なモデルに対して整合を求めます。それらは設計時に書くものであり、入力ではありません。
|
|
11
|
+
|
|
12
|
+
まあ質問者さんの意図はよく分かりませんが、「こうしなければならないか？」は知りたいようなので、それに対しては「(要件次第なので必ずしも)しなくていいよ」でいいのかと思います。一言で言えば「要件が足りないので、誰も答えを持っていない」というだけです。
|