4 + 1アーキテクチャビューモデルとUML間のマッピング
4 + 1アーキテクチャビューモデルがUMLにどのようにマップされるかについて少し混乱しています。
Wikipedia は次のマッピングを提供します：
- 論理図：クラス図、通信図、シーケンス図。
- 開発ビュー：コンポーネント図、パッケージ図
- プロセスビュー：アクティビティ図
- 物理ビュー：配置図
- シナリオ：ユースケース図
ペーパー オブジェクトライフサイクルコンセプトにおけるUMLシーケンス図構成の役割 は、次のマッピングを提供します。
- 論理ビュー（クラス図（CD）、オブジェクト図（OD）、シーケンス図（SD）、コラボレーション図（COD）、状態図（SCD） ）、アクティビティ図（AD））
- 開発ビュー（パッケージ図、コンポーネント図）、
- プロセスビュー（ユースケース図、CD、OD、SD、COD、SCD、AD）、
- 物理ビュー（配置図）、および
- 上記の4つを組み合わせたユースケースビュー（ユースケース図、OD、SD、COD、SCD、AD）。
Webページ ML 4 + 1資料を表示 は、次のマッピングを示しています。
最後に、ホワイトペーパー ML 2での4 + 1ビューアーキテクチャの適用 は、さらに別のマッピングを提供します。
- 論理ビュークラス図、オブジェクト図、状態図、および複合構造
- プロセスビューシーケンス図、コミュニケーション図、アクティビティ図、タイミング図、相互作用概要図
- 開発ビューコンポーネント図
- 物理ビュー配置図
- ユースケースビューユースケース図、アクティビティ図
さらに検索すると、他のマッピングも明らかになると思います。
通常、さまざまな人が異なる見方をしていますが、なぜこれが当てはまるのかわかりません。特に、各UML図は特定の側面からシステムを説明しています。それでは、たとえば、「シーケンス図」が1人の作成者によるシステムの「論理ビュー」を説明していると見なされ、別の作成者が「プロセスビュー」を説明していると見なすのはなぜですか。
混乱を明確にしてくれませんか。
私は一般的に Bart van Ingen Schenauの答え に同意しますが、いくつかの点についてさらに詳しく説明する必要があると思います。
4 + 1ビューモデルの利点は、特定のモデリング表記法を使用する必要なく、関係者が必要な情報のタイプにマッピングできることです。重要なのは、すべてのグループがシステムを理解して仕事を続けるための情報を確実に入手できるようにすることです。
ソフトウェアアーキテクチャの4 + 1ビューモデルは Philippe Kruchtenの論文Architectural Blueprints-The "4 + 1" View Model of Software Architecture これはIEEEソフトウェア（1995年11月）で最初に公開されました。この出版物は、UMLへの特定の参照を行いません。実際、このペーパーでは、論理ビューに Booch表記 を使用し、プロセスビューと開発ビューのBooch表記を拡張し、物理ビューを開発する「いくつかの形式」の使用を呼びかけています。シナリオの新しい表記。
各ビューを特定の種類の図にマップするのではなく、各ビューの対象ユーザーが誰で、どのような情報が必要かを検討します。それを知って、さまざまなタイプのモデルと、どのモデルが必要な情報を提供しているかを見てください。
論理ビューは、必要なすべての機能がシステムに確実に取り込まれるようにするというエンドユーザーの懸念に対処するように設計されています。オブジェクト指向システムでは、これは多くの場合クラスレベルです。複雑なシステムでは、パッケージビューが必要な場合があり、パッケージを複数のクラス図に分解します。他のパラダイムでは、モジュールとそれらが提供する機能を表すことに興味があるかもしれません。最終的には、必要な機能を、その機能を提供するコンポーネントにマッピングする必要があります。
プロセスビューは、システム全体を設計し、サブシステムまたはシステムをシステムのシステムに統合するユーザー向けに設計されています。このビューには、システムが持つタスクとプロセス、外部とのインターフェース、システム内のコンポーネント間のインターフェース、送受信されるメッセージ、パフォーマンス、可用性、フォールトトレランス、および整合性への対処方法が表示されます。
開発ビューは主に、モジュールとサブシステムを構築する開発者向けです。モジュール間の依存関係と関係、モジュールの構成、再利用、移植性を示す必要があります。
物理ビューは、主にソフトウェアの物理的な場所、ノード間の物理的な接続、展開とインストール、およびスケーラビリティを理解する必要があるシステム設計者と管理者向けです。
最後に、シナリオは要件の把握に役立ち、すべての関係者がシステムの使用方法を理解できるようになります。
各ビューが何を提供することになっているのかを理解したら、使用するモデリング表記法と必要な詳細レベルを選択できます。 Bartの最後の段落は特に当てはまります。特定の設計要素に焦点を合わせるか、さまざまなタイプの図を組み合わせて1つのセットにすることにより、UMLモデルにさまざまなレベルの詳細を表示できます。さらに、システムアーキテクチャをより適切に説明するために、UMLを超えて他のモデリング表記に移行することを検討することをお勧めします- SysML 、 Entity-Relationモデリング 、または [〜 ＃〜] idef [〜＃〜] 。
4 + 1建築モデルのビューとさまざまなUMLダイアグラムの間に1対1のマッピングが見つからない理由は、そのようなマッピングが存在しないためです。
これらすべての作成者が「マッピング」で伝えようとしているのは、ビューごとに、そのビューで伝えたい情報を伝えるのに役立つさまざまなUML図があることです。
さらに、いくつかのUMLダイアグラムは、ダイアグラム内のさまざまな要素を強調することにより、さまざまな方法で使用できるため、複数のビューで役立ちます。ただし、1つのUML図タイプを複数のビューで使用できる場合でも、ビューごとに異なる図（または図のセット）を描画します。
エンドユーザーのニーズに応えるための Thomas Owensの回答 アプローチには同意しますが、言及されていないことの1つは、 "4 + 1 View Model Architecture "by Kruchten UMLへの具体的な参照はありません。記事は1995年に（回答の状態として）作成されたためですが、UMLは実際には標準として採用されていません 1997年まで 。
Grady BoochはUMLの開発に携わった人物の1人であったため、記事でBooch表記を継続的に使用すると、各モデルビューを特定のUMLダイアグラムに関連付けることが適切である可能性があります。
これは、4 + 1モデルの元の定義が依存するBooch表記のいくらかの「抽象化」で複数のUMLダイアグラムが考慮される可能性があるため、非常に多くの異なる作成者が異なるUMLダイアグラムを各ビューに適用できると見なしているためです。各ビューを表す。
これにより、これを調べている他の誰にとっても、もう少し問題が解決することを願っています。
1995年に購入したVCRをまだ使用していますか？ 4 + 1は、ソフトウェアがまだ登場していない頃に適用可能でした。しかし、それでも、2つまたは3つを超える「ビュー」を使用したことはありません。過去20年間で、ソフトウェアエンジニアリングは変化しました。現在、スコープ/コンテキスト、概念的、論理的、物理的、および...はすべて区別されています。多くのCOTSソリューションを統合する必要があります。今日、私たちはランドスケープマップ、サービスの実現、および他の何十ものビューとビューポイントについて話しています。それを見る最善の方法は、Zachmanのような単純な分類フレームワークを使用することです：6つのビューと6つの視点。それを出発点としましょう。 6つのビューは次のとおりです。コンテキストの概念またはビジネスの論理またはシステムの物理またはテクノロジーの提供または成果物機能企業
6つの視点は次のとおりです。データ、機能、ネットワーク、場所、人、時間、動機、理由
例を見てみましょう。データのみに関心がある場合は、スコープビューから始めて、「私たちのスコープはCRM」と言います。データの視点の概念図では、CRMのセマンティックモデルを考え出します。モデルは、データオブジェクトではなく、概念的なビジネス情報の概念になります。次に、論理ビューで、CRMの概念モデルから論理データモデルを作成します。 ER手法を使用して論理データモデルを作成する場合があります。次に、物理ビューで、物理データモデルを作成します。ここでは、選択したdbプラットフォーム、インデックスなどの具体的なデータ型を定義します。最後に、配信ビューにはDDLスクリプトがあり、機能しているエンタープライズビューでは、バイナリファイルがデータベースサーバーにデプロイされています。 DBMベンダーの内部データ構造にマッピングされます。これをすべての視点または列について繰り返します。また、複数の利害関係者がいる場合は、視点/ビューの組み合わせごとに複数のモデルを作成します。これでこの分類法が整ったので、独自の視点とビューを定義して、これらをこの分類法に合わせることができます。たとえば、エンタープライズレベルのイニシアチブでは、次の視点がすべて重要です。
Krutchenの4 + 1はこれらのニーズのすべてを満たすことができなかった