UML ダイアグラムを作成するときに従う必要がある順序は何ですか
番号を付けて、必須として表示できますか?
私の考えでは、以下のようになるはずです:
- ユースケース (必須)
- シーケンス (必須)
- アクティビティ
- 州
- コラボレーション
- クラス (必須)
間違っている場合は修正してください!
UML ダイアグラムを作成するときに従う必要がある順序は何ですか
番号を付けて、必須として表示できますか?
私の考えでは、以下のようになるはずです:
間違っている場合は修正してください!
一般的な意味では、従う必要のあるシーケンスはなく、図は必須ではありません。
順序付けを規定し、どの図を作成するかを規定するUML中心の方法論(たとえば、他の場所で言及されているRUP、FDD、ICONIX)があります。
したがって、書かれた質問に対する答えは次のとおりです。
UMLベースの開発アプローチを採用しようとしている場合は、さまざまな方法論を検討し、どちらを使用するかを決定することをお勧めします。これにより、質問に答えることができます。
でも。 そのすべてをオーバーライドする:UMLはツールのセットです。それらを有用なときに使用し、プロセスのために処理するためのスレーブにならないでください。
hth。
「 UMLベースの開発アプローチ」のようなものはありません。
UML は単なる表記です。あなたを導くのは「プロセス」ではありません:
Role ---> Activity ---> Artifact
そのようなガイドが必要な場合は、Rational Unified Process を参照してください。または、より軽量なオープン バージョンの OpenUP http://www.eclipse.org/epf/downloads/configurations/pubconfig_downloads.phpをダウンロードできます
しかし、どのソフトウェア プロセスも、服を買いに行くようなものではありません。すべてのプロセスは、プロジェクト固有のニーズに合わせて調整する必要があります。そうしないと、「プロセス」はソフトウェアプロジェクトを強制終了します。Sfinnie は絶対に正しいです。
彼の著書 Larman (Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development) では、Rup with Uml を軽量な方法で適用しています。
Uml の使用方法を簡単に説明します ( http://www.objectsbydesign.com/books/larman_process.html ) 。
注意してください UML フィーバーで死んではいけません!!! UML フィーバーによる死亡
ユースケース図、クラス図、オブジェクト図、状態図、シーケンス図、コラボレーション図、アクティビティ図、配置図、コンポーネント図
以下のリンクを参照してください
http://www.globalshiksha.com/What-is-the-sequence-of-UML-diagrams-in-project-/ugc/4151036607101480
あなたの順序はほぼ正しいように見えますが、プロジェクトの UML ダイアグラムを作成するための必須の順序があるかどうかはわかりません。都合の良いときに、UML から抜け出すことができるはずです。
UML の使用方法を構造化したい場合は、世の中にあるさまざまなソフトウェア モデリング プロセスを調べる必要があります。私がかなり使用したのは、ICONIX プロセス ( http://www.informit.com/articles/article.aspx?p=167902 )です。これは、ユースケースに基づく軽量プロセスです。
IT プロジェクトでは、UML 図に基づいて、いわゆるプロジェクト図を作成します。UML ダイアグラムを使用するプロジェクトの大部分 (Choi, H., Yeom, K.: アーキテクチャの 4+1 ビュー モデルによるソフトウェア アーキテクチャ評価へのアプローチ。In: 第 9 回アジア太平洋ソフトウェア エンジニアリング カンファレンス、pp. 286—293) IEEE Computer Society、2002)、(Kennaley M.: The 3+1 Views of Architecture (in 3D): An Amplification of the 4+1 View-point Framework. In Seventh Working IEEE/IFIP Conference、pp. 299—302 . IEEE コンピューター ソサエティ、2008 年) では、ソフトウェアベースのシステムの主な機能を説明するために、ソフトウェア開発の開始時にユース ケース図が作成されます。次に、システムの構造を示すクラス図が作成され、システムの要素の動作を示すステート マシン図が作成されます (Issa A.、Abu Rub FA: Performing Early Feasibility Studies of Software Development Projects Using Business Process Models, Proceedings of the World Congress on Engineering-ing 2007 Vol I WCE 2007, July 2 - 4, 2007, London, UK), (Dijkman RM, Joosten SM: An Algorithm to へのアルゴリズム) Derive Use Case Diagrams from Business Process Models、第 6 回ソフトウェア エンジニアリングおよびアプリケーションに関する国際会議 (SEA)、アナハイム、カリフォルニア、米国、Acta Press、pp. 679-684、2002)。その後、アクティビティ図またはシーケンス図を使用して、他の図の一貫性を検証できます。これらの図は、視覚化シナリオ、つまりユースケース実現図も使用しています。しかし、UML プロジェクトでは、最初にアクティビティ UML 図に基づいてコンテキスト図を作成します。コンテキスト図には、1 つのメイン プロセス、入力時のいくつかのイベント、および出力時のいくつかの製品またはサービスが含まれます。次に、分解図を作成します。次に、ビジネス ユース ケース図を作成できるようにします。さて、ユースケースごとに、まずアクティビティ図をもとにユースケース実現図を作成します。各ユース ケース実現図から、クラス、状態、およびシステムのユース ケース図を導き出します。次に、システム ユース ケース図に基づいてシーケンス図を作成し、IT システムの内部動作と構造を示します。最後に、コンポーネント図(シーケンス図に基づく)と展開図(コンポーネント図に基づく)を作成します。スタニスワフ・イェジー・ニーポスティン、project-media.pl 次に、システム ユース ケース図に基づいてシーケンス図を作成し、IT システムの内部動作と構造を示します。最後に、コンポーネント図(シーケンス図に基づく)と展開図(コンポーネント図に基づく)を作成します。スタニスワフ・イェジー・ニーポスティン、project-media.pl 次に、システム ユース ケース図に基づいてシーケンス図を作成し、IT システムの内部動作と構造を示します。最後に、コンポーネント図(シーケンス図に基づく)と展開図(コンポーネント図に基づく)を作成します。スタニスワフ・イェジー・ニーポスティン、project-media.pl