プログラムの高レベルのアーキテクチャを文書化するための標準はありますか？

私はアマチュア開発者であり、これまでのすべてのプログラムは、コード内に文書化できるほど単純でした。コードを読んでいる間、私が何をしているのか、そのようなアクションは明らかでした（私の標準的なテストは、6か月後にコードを見て、最初に読んだときにすべてを理解することでした-私は短いメモリスパンを持っています）。

私は今、プログラム間のさまざまな相互作用を覚える能力を超えてプログラムに直面しています。

• コード自体
• データベース内のインデックス
• さまざまなモジュール間の相互作用（「ワーカー」コアコードと「ライブラリ」モジュール）

私の現在のドキュメントはホワイトボードで、コード、データベースインデックス、実行中のアクション、状態変化などを指すあらゆる種類のボックスと矢印があります。参考までに、混乱の断片：

私の質問は、より複雑な製品のドキュメント化のための標準または名前付きのベストプラクティスのセット（これは特定の名前でグループ化された一連のプラクティスであるという意味で名前が付けられている）があるかどうかです。

私が探す必要があるキーワードは何ですか（「ドキュメントソフトウェアアーキテクチャ標準」での一般的な試みと同様のバリエーションは、通常、ワークフローまたはビルディングアーキテクチャCADシステム用のソフトウェアにつながりました）。

また、高レベルの説明には一般的なベストプラクティスがなく、誰もが独自の哲学を構築することも期待しています。

誰もが遵守している基準は1つではありません。ソフトウェアプロジェクトは大きく異なる可能性があります（helloworld.pyとスペースシャトルのコードを比較してください）。

非常に一般的な方法の1つは、4 + 1モデルを使用することです。すべてを単一のスタイルのドキュメントに詰め込もうとする代わりに、この方法論は設計を5つのコンポーネントに分割します。

• 開発ビュー
• 論理ビュー
• 物理ビュー
• プロセスビュー
• シナリオ

さまざまなビューは、4つの異なる視点から製品を説明しています。シナリオはユースケースが存在する場所であり、他のビューの相互作用を説明します。

注：これは概念モデルであり、特定のツールに関連付けられていません。

あなたはここでもっと読むことができます：

1. 4 + 1建築ビューモデル（ウィキペディア）
2. アーキテクチャの青写真—ソフトウェアアーキテクチャの「4 + 1」ビューモデル（IEEE論文-pdf）

IMHO UMLは、実際のソフトウェアのアーキテクチャを文書化するために適切に機能するツールではありません。クラス図は便利ですが、この目的には低すぎることが多い抽象化レベルを使用します。ユースケース図は一般的に「高レベル」であり、特定の側面を見逃しています。他のUMLダイアグラムタイプにも同様の問題があります（公平に言うと、パッケージダイアグラム、デプロイメントダイアグラム、コンポーネントダイアグラムは、特定のアーキテクチャーの側面を文書化できますが、個人的にはあまり有用だとは思いませんでした）。

高レベルのアーキテクチャを文書化する実用的で実用的な方法を探している場合は、データフロー図に慣れることをお勧めします。これらは理解しやすく、抽象化のさまざまなレベルに拡張できるという利点があります。さまざまな種類のシステムを文書化するのに最も役立つことがわかりました。UMLへの道を見つけられなかったのは残念ですが、それにもかかわらず、これらの図を作成するためのツール（DiaやDrawIOなどの無料のツールでさえ）がたくさんあります。

補足として、高レベルのドキュメントに「データベースのインデックス」が必要なのはなぜですか？（リレーショナル？）データモデルの実装の詳細であると思います。それらを追加するかどうかは、私の経験では、パフォーマンスと最適化の問題です。

統一モデリング言語（UML）は、ソフトウェアエンジニアリングの分野における汎用の開発モデリング言語であり、システムの設計を視覚化する標準的な方法を提供することを目的としています。

以前はもっとうまくやったと思います。UMLは、赤ちゃんを風呂の水で捨てたようです。統一モデリング言語を提供することで、アーキテクチャと実装の区別がなくなりました。または、それが意図していなかった場合、効果があるように思われました。

私はいくつかの怪物のUMLモデルを見てきましたが、率直に言って、コードが実行できなかったことを何も実行せず、より適切に実行します。