開発前に最新のアプリケーションをモデリングするための標準は何ですか？

私は最初のエンタープライズレベルのアプリケーションに取り掛かっています。コードを1行もタップする前に、チームでASP.NET MVC C＃アプリケーション全体をモデル化してください。

更新：これは、いつアプリケーションを文書化/モデル化するかについての哲学的議論を意図したものではありませんでした。文書化/モデル化の「方法」についてのみ回答を提供してください。

真実は、私がこの部門で常に失敗したことがあり、アプリケーションをこれまで実際にモデル化したことがないということです。これを行うための標準的な方法は何ですか？どのタイプの図を使用する必要があり、ドキュメントはどのように見えますか？サンプルの図とドキュメントへのリンクは高く評価されています。

検索するとき、私はネット上で多くのことを見つけることができますが、これを行う方法について現在のコンセンサスがあるかどうかを確認したいと思いました。

前もって感謝します！

おわりに

私はこれがそんなにねばねばした主題であるとは知りませんでした。明白な論争を取り除き、有用な回答を提供してくれた皆さんに感謝します。控えめに言っても興味深い議論でした:)

私が発見した別の便利なリンクはこれです：https : //stackoverflow.com/questions/61487/do-you-use-uml-in-agile-development-practices/61519#61519

現在のコンセンサス

真実は：現在、それは現代のソフトウェア開発に欠けているものです-モデリングについてのコンセンサス。UMLはある種の最小公約数であるように見えますが、実際には、表記法についてのみコンセンサスがあり、意味論についてではありません。コードを作成するためにUMLをどのように解釈する必要があるかについては、さまざまな意見が存在します（おそらく、チームにとって適切な解釈を1つ見つけることができます）。

一方、「正式なモデルを作成しないで、作業コードをよりよく書く」と言っている「アジャイル」な人々と「 MDA」（モデル駆動型アーキテクチャ）がソリューションです。

他の人々は、UMLの代替として、最新のソフトウェア設計のためのフローベースのプログラミングを（再）発見しました。詳細については、こちらとこちらをご覧ください。

1行のコードを取り出す前に、ASP.NET MVC C＃アプリケーション全体をモデル化したい

私がこのようなアプローチで通常見つける問題は、ソリューションに対する私の理解が最初は常に不完全であることです。私が最終的な解決策にたどり着くのは、作業が進むにつれて洗練することだけです。

コード全体（非常に単純なアプリを除くすべて）の前に、アプリ全体を前もって設計しようとすることは、通常、愚かです。

すべてのクラス、メソッド、データ構造を事前に詳細にレイアウトできると本当に信じていますか？

いくつかの優れたモデリングソリューションを知りたいだけです。

モデルを作成するための実際のツールについては、いくつか試してみましたが、常にMicrosoft Visioに戻りました。

私が試したすべての製品の中で、それは最も簡単で、実際には安定しているように見えます（モデリングツールの私の経験では、非常にバグが多いです）。公平を期すために、私はほとんどモデリングを行っていないので、この推奨事項を1粒の塩でとってください。

編集：実際には、私のモデリングのほとんどは机の上にあるメモ帳で行われていると言うべきです。私はモデリングをほとんど行わないので、それを軽量かつ適切に保つようにします。ペンと紙で図をスケッチする方が、ソフトウェアを使用するよりもはるかに効率的です。

手書きの図表は、図表作成ソフトウェアでレイアウトする前に、アイデアを形成するのに役立ちます。

どのタイプの図を使用する必要があり、ドキュメントはどのように見えますか？

最近私がモデル化しているもののほとんどは相互作用図です。繰り返しますが、私はモデリングをあまり行いません。モデルを描く練習が本当に理解を深めるのに役立つと感じているところだけです。

UMLダイアグラムは、始めるのに適した場所です。無料または有料のソフトウェアでこれを行う簡単な方法は数多くあります。UMLを作成するためのツールの1つの簡単な例は、Googleドキュメントの図面のようなものです。より高度なパッケージは、VisioまたはOmniGraffleです。

編集：多くの人が言及したように、UMLパスをたどったとしても、すべてを完全にモデル化する必要があるという意味ではありませんが、モデル化する対象と、モデルが必要とする詳細度についてコンセンサスを得ることができますあります。単純なUMLダイアグラムは、コードを記述する前にレイアウトするのに役立ち、潜在的な問題が発生する前に解決するのに役立ちます。

@Brettが示唆したように、UMLダイアグラムが最適です。UMLでは、クラス図とワークフロー図があると便利です。これらの2つは、ほとんどの設計ニーズをカバーします。

クラス図を使用すると、各エンティティのメンバー、セキュリティレベルなどをモデル化できます。

ワークフロー図を使用すると、どのメソッド呼び出し、どの呼び出し、ワークフローの結果、およびポップアウトする可能性のある例外をモデル化できます。

コードを書く前に基本的な建築図面を作成することを強く信じていますが、アプリ全体の詳細な図面を作成するのは大変な作業だと思います。

私は通常、Visioでいくつかのアウトライン画像を作成します。多くの場合、「フローチャート」のビルディングブロックを使用して、私の意味を視覚化しています。UMLを使用すると、形式化されているように感じられ、あまりにも詳細に招待されます。Visio図面は、アプリケーションの基本的なビルディングブロックと、どのタイプの機能がどこに配置されるかを示しています。MVCフレームワークを使用している場合、ほとんどの場合、Webからサンプルを取り出してコピーするだけです。

他の観点からいくつかの図面を作成することをお勧めします。すべてを描くのではなく、システムの特定の機能を1つ取り、それを次のように視覚化することを好みます。

• ユースケース図（UML）
• フローチャートまたはUMLスイムレーン（非常に高レベル）
• 建築コンポーネントの概要。

次に、コーディングを開始します。コーディング中、オンザフライのクラス図、継承などを取得するためにドット統合でdoxygenを使用しています。doxygenで生成された概要を表示することは、多くの場合、コード構造を確認するのに非常に良い方法です。