ソフトウェアアーキテクチャモデリング
システム/ソフトウェアアーキテクチャの設計をクライアントに提示するために space-based architecture（SBA） を視覚的にモデル化する最善の方法に少し混乱しています。
このモデリングの目的は、以下を示すことです。
- システムの主要コンポーネント（例：データベース、サーバー公開API、クライアント、サーバーワーカー、クライアント公開API）
- これらの主要コンポーネント間の相互作用
- 主要なエンドツーエンドのワークフロー
現在、スイムレーンでBPMN2表記を使用することを考えています。 UML2表記のシーケンス図とユースケース図。
このアプローチが最善であるかどうかわからない、いくつかのフィードバックを得るために素晴らしいでしょう:)
前の回答に同意します。そこに述べられているように、質問で述べられているモデルタイプはあなただけでは役に立ちません。
重要なデータモデルまたはビジネスドメインの場合は、エンティティ関係図から始めることをお勧めします。わかりやすく、いくつかの記号がすぐに説明されます。エンティティの適切な定義を含めます。これにより、誰もがドメインを同じように理解できるようになります。カーディナリティとの関係も、多くの誤解を事前に解決します。
通常、ブロック図は、アーキテクチャのランタイム構成を示す主要な図です。プロトコルとシステムの境界を示します。目的に合った抽象化レベルを選択し、表示する要素をできるだけ具体的にします。例えば。通信チャネルで、誰が要求を開始したか、データフローの方向、および使用されたプロトコルを示します。各コンポーネントの目的と接続を、それが自明ではない場合や明白でない場合に備えて、モデルの下の追加のテキストで説明します。
SAPは、アーキテクチャにスリム化されたUMLバージョンを使用します（説明 here ）。
必要に応じて、他の種類の図を使用できます。
ランタイムビューとは異なるアーキテクチャの設計時ビューが存在する可能性があることを忘れないでください。例えば。ランタイム用のコンパイラーによって折りたたまれているレイヤーがデザインタイムにある場合があります。
アーキテクチャモデリングと表現では、対象者と、設計された構造とその決定の根拠を最も簡単かつ正確に伝えるための表記法を考慮する必要があります。
2つの良い点-
- 文書化された「標準」アーキテクチャスタイル（SBA）を使用すると、パターン認識によるコミュニケーションに役立ちます。誰かがそのスタイルを知っている場合、それを使用していることを知っていれば、その人はより簡単に理解できるようになります。
- 文書化された「標準」表記法を図表に使用すると、表記法を知っている人が構造と意味をより簡単に推測できるようになるため、読みやすさが向上します。
もちろん、注意すべきことは、誰もがスタイルと表記法をすでに知っているとは限らないため、標準の作図のベストプラクティス（凡例、明確なラベル、パースペクティブの混合ではなく、複数のビューとビューポイントなど）を使用する必要があることです。
アーキテクチャー表現のUML表記に関する他の唯一の難点は、オブジェクト指向設計用に設計された表記法を使用してアーキテクチャーレベルの概念をダイアグラム化することが難しい場合があることです。あなたが言及した記法のどちらがアーキテクチャのモデル化にどのように役立つかはわかりません。ユースケースは単なる写真ではありません。また、ビジネスプロセスモデリングは、動的、静的、または物理的な構造とは関係ありません。