ワークフローのモデリングとデータベースとの相互作用-迅速でアクセス可能なオプション
トレーサビリティデータベースとの相互作用に特に重点を置いて、（提案された）製造ラインをモデル化したいと考えています。つまり、さまざまなプロセスエンジニアがすでに製造プロセスをマッピングしています。私は、DBと通信する必要のあるライン上のさまざまなステーションにのみ関心があります。
対象読者は、プロジェクトマネージャー、エンジニア、IT担当者の混合です。目的は、以下を特定することです。
- ラインがDBと相互作用するポイント（おそらく、各ポイントで呼び出されたStore Procsを示し、おそらくどのパラメーターが渡されるかを示します）。
- 通信ソース（PC /ハンドヘルドデバイス/ PLC）
- 通信媒体（無線/ファイバー/銅）
- 制御フロー（リークテストが失敗した場合、ユニットは修理ステーションに迂回されます）
基本的に、このモデルは、さまざまなグループが未解決のタスクに焦点を当てるために使用されます。たとえば、DBと必要なフロントエンドアプリに興味があります。プロセスエンジニアはワークフローについて考え、PLCサプライヤと連絡を取る必要があります。他のIT担当者は、ハードウェアと通信が適切に配置されていることを確認する必要があります。 。
もちろん、Visioで即興で演奏することもできましたが、自分のニーズや聴衆に特に適した特定のモデリング手法があるかどうか疑問に思いました。私は、サポートドキュメントを備えたビジュアルモデルを考えています（可能な限り少なく、必要なだけ）。
明らかに、私は（効果的に）学ぶのに何年もかかるようなものも、プロジェクトチームの非技術的なメンバーを遠ざけるようなものも望んでいません。
これまで、BPMN、EPCダイアグラム、標準のフローダイアグラムを簡単に見てきましたが、UMLについて知っていたことのほとんどを忘れてしまいました。そして、ピッキングとミキシングに反対していません。迅速、明確、効果的である限り。
結論：
最終的に、私は準ワークフロー/データフロー図を選択しました。トレーサビリティDBと相互作用する製造プロセスの部分をマッピングし、データフローとDBアクティビティを大幅に簡略化した形式で示しました。それに加えて、各プロセスの概要、各プロセスで処理されるデータ（ある種の「データディクショナリ」）、および必要なハードウェアと接続の詳細を説明するサポートドキュメントがあります。
天才の産物なのか、確立されたソフトウェア開発慣行に対する犯罪なのかを判断することはできませんが、私はdoそれがこの特定の聴衆の目印になると思います。
管理者、エンジニア、IT担当者を満足させるのに十分な詳細の図を1つ作成することは困難です。 IT担当者は、sprocパラメータを知りたがり、エンジニアは障害のケースを心配し、マネージャーはすべての詳細に飽きて、ブラックベリーをいじり始めます。
プレゼンテーションのポイントは何ですか？あなたが言った -
モデルは、未解決のタスクに関するさまざまなグループの焦点として使用されます。たとえば、DBと必要なフロントエンドアプリに興味があります。プロセスエンジニアはワークフローについて考え、PLCサプライヤと連絡を取る必要があります。他のIT担当者は、ハードウェアと通信が適切に配置されていることを確認する必要があります。 。
まず、プレゼンテーションをプロジェクト計画ではなく地図として考えます。管理者が理解できるようにシンプルにし、エンジニアやIT担当者も理解できるようにします。 （その逆は真実ではありません。）
次に、可能な限り最も単純で最も明白な図を使用します。ダイアグラムが乱雑になったり大きくなりすぎたりしないように、詳細については脚注でダイアグラムに注釈を付けます。
最初のプレゼンテーションの目的はプロジェクト全体の共通のグループ理解を達成することであると想定しています。そのために、DBの相互作用のポイントを示すために、稲妻の線で各コンポーネントの写真を使用することをお勧めします（DBアイコンの束で図を乱雑にしないでください。または、すべての相互作用線を1つのDBアイコンに結び付けてみてください。それは図を乱雑にし、価値を追加しません）。各インタラクション行に脚注番号を付け、参照用に別のページに脚注を印刷するだけです。プレゼンテーションスライドに脚注を表示するのではなく、脚注について話し、図を参照してください。脚注を配布物として利用できるようにするか、後で投稿/電子メールで送信します。全体像を理解することに聴衆を集中させます。共通の理解に達したら、フォーカスチームに詳細を考えさせます。
Omondoは、データベースプロファイルを作成することにより、物理（データベースなど）と論理（UMLオブジェクトなど）の統合をカバーするという野心的な試みを行いました。私はツールを使用しましたが、それが本当にうまく機能したことを認めなければなりません。アイデアは、モデルとデータベースのステレオタイプとライブ同期したコードでJavaアノテーションを作成することです。
このツールで私が気に入っているのは、完全なpojoサポートです。オブジェクトからデータベースへ、そしてデータベースからモデルへ。私にとっては素晴らしい!!
システム全体を効果的に伝達するために単一のモデルを見つけようとするのはばか者の用事です。 RUPがAgilistsの支持を失ったことを私は知っています。しかし、本当の問題は、いくつかのアジャイルプロジェクトで見られるのと同じ問題だと思います。人々はそれを完全に理解せずにアプローチを使おうとしました。
デザインを聴衆に効果的に伝えるために必要なだけのドキュメントを作成したいとおっしゃいました。これは一言で言えばRUPです。カタログ内のすべてのアーティファクトに記入する必要はありません。これは、通信の開始点として、いくつかのアーティファクトとテンプレートを提供するだけです。どれが必要かを決めるのは個人の責任です。
Scott Amblerによって書かれた、このアプローチ（eXtreme Unified Processと呼ばれる）について説明しているすばらしい本 Agile Modeling があります。
編集：まだ読んでいませんが、アジャイルモデリングの姉妹本 アジャイルドキュメント もあるようです。
物理アーキテクチャと論理アーキテクチャの両方をカバーしたいと考えているようです。ですから、あなたにとって最も簡単なものを使用し、ラベルとキーが明確であることを確認してください！