4 + 1アーキテクチャビューモデルとUML間のマッピング

4 + 1アーキテクチャビューモデルがUMLにどのようにマッピングされるかについて、少し混乱しています。

ウィキペディアは次のマッピングを提供します。

• 論理ビュー：クラス図、コミュニケーション図、シーケンス図。
• 開発ビュー：コンポーネント図、パッケージ図
• プロセスビュー：アクティビティ図
• 物理ビュー：展開図
• シナリオ：ユースケース図

「オブジェクトライフサイクルコンセプトにおけるUMLシーケンス図の構造の役割」というペーパーは、次のマッピングを提供します。

• 論理ビュー（クラス図（CD）、オブジェクト図（OD）、シーケンス図（SD）、コラボレーション図（COD）、状態図図（SCD）、アクティビティ図（AD））
• 開発ビュー（パッケージ図、コンポーネント図）、
• プロセスビュー（ユースケース図、CD、OD、SD、COD、SCD、AD）、
• 物理ビュー（展開図）、および
• 上記の4つを組み合わせたユースケースビュー（ユースケース図、OD、SD、COD、SCD、AD）。

WebページUML 4 + 1 View Materialsは、次のマッピングを提示します。

最後に、ホワイトペーパー「UML 2で4 + 1ビューアーキテクチャを適用する」では、さらに別のマッピングを提供しています。

• 論理ビュークラス図、オブジェクト図、状態図、複合構造
• プロセスビューシーケンス図、コミュニケーション図、アクティビティ図、タイミング図、相互作用概要図
• 開発ビューのコンポーネント図
• 物理ビュー展開図
• ユースケースビュー、ユースケース図、アクティビティ図

さらに検索すると、他のマッピングも明らかになると確信しています。

通常、さまざまな人々が異なる視点を持っていますが、ここでなぜそうなのかわかりません。特に、各UML図は、特定の側面からシステムを説明しています。それで、例えば、なぜ「シーケンス図」はある著者によってシステムの「論理的見解」を記述すると見なされ、別の著者は「プロセス図」を記述すると見なされるのでしょうか？

混乱を明確にするのを手伝ってもらえますか？

バート・ファン・インゲン・シェナウの答えには概ね同意しますが、いくつかの点についてはさらに詳しく説明する必要があると思います。

4 + 1ビューモデルの利点は、特定のモデリング表記を使用する必要なく、利害関係者を必要な情報のタイプにマップすることです。重要なのは、すべてのグループがシステムを理解し、仕事を継続するための情報を持っていることを確認することです。

ソフトウェアアーキテクチャの4 + 1ビューモデルは、Philippe Kruchtenの論文Architectural Blueprints- IEEE Softwareで最初に発行されたソフトウェアアーキテクチャの「4 + 1」ビューモデル（1995年11月）で説明されています。この出版物は、UMLを具体的に参照していません。実際には、紙が使用するBooch法表記論理ビューのために、プロセスビューと展開図のためのBooch法表記の拡張機能は、物理的なビューを開発する「いくつかの形式」、およびシナリオのための新しい表記法の使用を呼び出します。

各ビューを特定のタイプの図にマップしようとする代わりに、各ビューのターゲットオーディエンスが誰で、どの情報が必要かを検討してください。それを知って、さまざまなタイプのモデルと、どのモデルが必要な情報を提供するかを見てください。

論理ビューは、目的の機能がすべてシステムに取り込まれるようにすることに関するエンドユーザーの懸念に対処するように設計されています。オブジェクト指向システムでは、これは多くの場合クラスレベルで行われます。複雑なシステムでは、パッケージビューが必要になり、パッケージを複数のクラス図に分解する場合があります。他のパラダイムでは、モジュールとそれらが提供する機能を表すことに興味があるかもしれません。最終結果は、必要な機能を、その機能を提供するコンポーネントにマッピングすることです。

プロセスビューは、システム全体を設計し、サブシステムまたはシステムをシステムのシステムに統合するユーザー向けに設計されています。このビューには、システムにあるタスクとプロセス、外界へのインターフェースやシステム内のコンポーネント間のインターフェース、送受信されるメッセージ、パフォーマンス、可用性、フォールトトレランス、整合性の対処方法が表示されます。

開発ビューは、主にモジュールとサブシステムを構築する開発者向けです。モジュール間の依存関係と関係、モジュールの編成方法、再利用、移植性を示す必要があります。

物理ビューは主に、ソフトウェアの物理的な場所、ノード間の物理的な接続、展開とインストール、およびスケーラビリティを理解する必要があるシステム設計者と管理者向けです。

最後に、シナリオは、すべての利害関係者がシステムの使用方法を理解できるように、要件を把握するのに役立ちます。

各ビューが提供するものを理解したら、使用するモデリング表記法と必要な詳細レベルを選択できます。Bartの最後の段落は特に真実です。特定の設計要素に焦点を当てたり、さまざまなタイプの図を組み合わせてセットにすることで、UMLモデルにさまざまなレベルの詳細を表示できます。さらに、システムアーキテクチャ（SysML、エンティティ関係モデリング、またはIDEF）をより適切に記述するために、UMLを超えて他のモデリング表記法に移行することを検討することもできます。

4 + 1アーキテクチャモデルのビューとさまざまなUMLダイアグラムの間に1対1のマッピングが見つからない理由は、そのようなマッピングが存在しないためです。

それらすべての著者が「マッピング」で伝えようとしているのは、ビューごとに、そのビューで伝えたい情報を伝えるのに役立つUMLダイアグラムの異なるセットがあるということです。

また、一部のUMLダイアグラムは、ダイアグラム内のさまざまな要素を強調することにより、さまざまな方法で使用できます。これにより、複数のビューで役立ちます。ただし、1つのUMLダイアグラムタイプを複数のビューで使用できる場合でも、ビューごとに異なるダイアグラム（または一連のダイアグラム）を描画します。

エンドユーザーのニーズに応えるトーマス・オーエンズの回答アプローチには同意しますが、言及されていないことの1つは、Kruchtenによる「4 + 1 View Model Architecture」の元の定義が何もしない理由です UMLへの具体的な言及は、この記事が1995年に書かれたためです（回答の状態として）が、UMLは実際には1997年まで標準として採用されませんでした。

この記事でBooch Notationを継続的に使用することは、Grady BoochがUMLの開発に関与した人物の1人であるため、各モデルビューを特定のUMLダイアグラムに関連付けることが適切であることを示唆しています。

4 + 1モデルの元の定義が依存しているのは、Booch Notationの「抽象化」で複数のUMLダイアグラムを考慮することができるためです。各ビューを表します。

これにより、これを検討している他の誰にとっても物事がもう少し明確になることを願っています。

1995年に購入したVCRをまだ使用していますか？4 + 1は、ソフトウェアがまだ初期段階にあった当時に適用可能でした。しかし、それでも、「ビュー」を2つまたは3つ以上使用した人はいませんでした。過去20年間で、ソフトウェアエンジニアリングは変化しました。現在、スコープ/コンテキストと概念的および論理的および物理的...はすべて区別されています。多くのCOTSソリューションを統合する必要があります。今日、私たちはランドスケープマップ、サービスの実現、およびその他の多数のビューとビューポイントについて話しています。それを見る最良の方法は、Zachmanのような単純な分類フレームワークを使用することです：6つのビューと6つの視点。それを出発点にしましょう。6つのビューは次のとおりです。コンテキスト概念またはビジネス論理またはシステム物理または技術配信または企業が機能するアーティファクト

6つの視点は次のとおりです。データ、機能、ネットワーク、場所、時間、動機、またはその理由

例を見てみましょう。データのみに関心がある場合は、スコープビューから開始して、「当社のスコープはCRMです」と言います。データの視点の概念図では、CRMのセマンティックモデルを考えます。モデルは、データオブジェクトではなく、概念的なビジネス情報の概念になります。次に、論理ビューで、CRMの概念モデルから論理データモデルを作成します。ER手法を使用して論理データモデルを作成する場合があります。次に、物理ビューで、物理データモデルを作成します。ここでは、選択したdbプラットフォーム、インデックスなどの具体的なデータ型を定義します。最後に、配信ビューではDDLスクリプトを使用し、機能するエンタープライズビューではデータベースサーバーに展開されたバイナリファイルを使用しますDBMベンダーの内部データ構造にマッピングされます。ビューポイントまたは列ごとにこれを繰り返します。また、複数の利害関係者がいる場合、各視点/ビューの組み合わせに対して複数のモデルを作成します。この分類法が整ったので、独自の視点とビューを定義し、これらをこの分類法に合わせることができます。たとえば、企業レベルのイニシアチブでは、次の視点がすべて重要です。アクター連携アプリケーション動作アプリケーション連携アプリケーション構造アプリケーション使用ビジネス機能ビジネスプロセスビジネスプロセス連携実装および展開情報構造インフラストラクチャインフラストラクチャ使用ランドスケープマップ概要階層化組織サービス実現など この分類法が整ったので、独自の視点とビューを定義し、これらをこの分類法に合わせることができます。たとえば、企業レベルのイニシアチブでは、次の視点がすべて重要です。アクター連携アプリケーション動作アプリケーション連携アプリケーション構造アプリケーション使用ビジネス機能ビジネスプロセスビジネスプロセス連携実装および展開情報構造インフラストラクチャインフラストラクチャ使用ランドスケープマップの概要階層化された組織サービスの実現など この分類法が整ったので、独自の視点とビューを定義し、これらをこの分類法に合わせることができます。たとえば、企業レベルのイニシアチブでは、次の視点がすべて重要です。アクター連携アプリケーション動作アプリケーション連携アプリケーション構造アプリケーション使用ビジネス機能ビジネスプロセスビジネスプロセス連携実装および展開情報構造インフラストラクチャインフラストラクチャ使用ランドスケープマップの概要階層化された組織サービスの実現など

クルッチェンの4 + 1は、これらのニーズをすべて満たすことはできませんでした