4

現在のクライアントアプリケーションを検証またはダウンロードするための忙しいルーチンのセットがあります。これは、.WSFファイルを呼び出すWindowsデスクトップショートカットから始まります。これにより、いくつかの.VBSファイル、設定用の.INI、および場合によっては.BATファイルが必要になります。これらのスクリプトドキュメントの一部には、内部機能があります。最終フェーズでは、AutoExecマクロを必要とするMicrosoft Accessデータベースを開きます。このマクロは、VBAに独自のロードルーチンを持つフォームを含む、一部のVBAを開始します。

この詳細は特に重要ではありません（したがって、VBAタグを追加したり、私の貴重な複雑さを批判したりしないでください）。重要なのは、私にはさまざまなツールとコンテナーがあり、それらは機能的にネストされている可能性があるということです。

フローチャートでそれを解析するためのより良いテクニックが必要です。現在、私は次のいずれかまたはすべてに依存しています。

  • 独特の色
  • ルーチンを囲む大きなボックス
  • 古典的な「制御の移転」シンボル
  • おそらく説明的な呼びかけ

フローチャートの語彙を増やすべきではありませんか？チュートリアルでは、正方形、ひし形、円などについて説明しています。確かにFCは私がこれらの種類のものに対処するのを助けることができます：

  1. たくさんのスクリプトタイプを使用すると、さまざまなニーズに答えることができます。ツール/言語を示したいと思います。
  2. サブルーチンは、タスク全体の中止またはエラーを引き起こす可能性があり、高レベルの「囲み」ルーチンによるその処理（またはその結果）を示したいと思います。
  3. 「内部」サブルーチンを別のスクリプトファイルのサブルーチンと区別したいと思います。
  4. 並行スクリプト処理が重要になる可能性があるので、注意したいと思います。
  5. .INIファイルを使用すると、すべてのルーチンに永続的な値を提供できます。それはどのようにグラフ化されていますか？
  6. 関数には引数と戻り値/参照がある場合があります...それでも効果的に引用する方法がわかりません。

ガイダンスを提供するか、非常に役立つリソースを教えてください。分析ツールセット（まだコツをつかんでいないUMLなど）をお勧めする場合は、良い紹介がどこにあるかも教えてください。

私はソフトウェアには興味がありません。これをホワイトボードの演習と考えてください。

4

1 に答える 1

0

質問の議論は、フローチャートが役に立たない、または正確ではないことを示唆しています。

精度は、フローチャートの作成方法によって異なります。それらが手動で構築された場合、それらは他の手動で構築されたドキュメントと同様に、ほぼ瞬時に古くなります。そのため、手作業で作成したフローチャートは本当に役に立たなくなります。これが、人々がコードを見るのを好む傾向がある理由です。

[この回答の残りの部分は、「(フローチャートを作成するための) ソフトウェアには興味がない」という OP の要件に違反しています。

フローチャートが適切な言語に正確な分析ツールによってコードから導出された場合、フローチャートは正確になります。http://www.semanticdesigns.com/Products/DMS/FlowAnalysis.htmlで例を参照してください。 これらの例は意味的に正確ですが、そこにあるページでは正確な意味論が提供されていませんが、それはドキュメントの詳細にすぎません。

そのようなツールを見つけるのは難しいです:-}特に、複数の言語にまたがるフローチャートと複数の「実行パラダイム」が必要な場合(OPは彼のINIファイルを含めることを望んでいます;それらはある種の暗黙の割り当てステートメントであり、彼はかなり確信していますテーブルに対する純粋な計算になる傾向があるため、有用なフローチャートを作成しない SQL アクションをモデル化する必要があります)。

また、そのようなフローチャートが有用かどうかも不明です。私が提供したページの例は、ある程度説得力があるはずです。すべての微視的な詳細 (たとえば、すべてのサブルーチン呼び出しから発生する ABORT 制御フロー アークの可能性 [各呼び出しが例外をスローする可能性があるため]) を考慮すると、これらの図は恐ろしく大きく高速になります。ダイアグラムがスペースを消費する (ボックス、ひし形、線、大量の空白) という事実は、これをかなり悪化させます。それらが大きくなると、弧を描いて文字通り宇宙で迷子になります。繰り返しますが、人々がシステム全体のフローチャートを避ける十分な理由です。(人々がテキスト言語を好むもう 1 つの理由は、テキスト言語が実際にはかなり密集している可能性があることです。簡潔な言語を使用すると、1 ページで多くの情報を得ることができ、APL が表示されるのを待ちます :)

関数が複雑なロジックを持っている場合、それらは個々の関数でわずかな助けになるかもしれません。

必要なすべての言語のフローチャートを生成する正確な言語のアナライザーを取得する可能性は低いと思います。そのようなアナライザーがフローチャートを適切に構成できるとは考えにくいです (SQL を実行する C# を呼び出す JavaScript が必要ですか?)

あなたが望むかもしれないのは、妥協の解決策です: 参照されている他のアーティファクトへのさまざまなハイパーリンクを含むコードを表示します。このようなハイパーリンク コードを生成する機能は引き続き必要ですが (これが機能する方法の 1 つについては、 http://www.semanticdesigns.com/Products/Formatters/JavaBrowser.htmlを参照してください)、言語の境界を越えたハイパーリンクも必要です。

現在、それを行うツールはありません。そして、あなたがそのようなツールを自分で構築することに興味や意志を持っているとは思えません。

于 2011-07-20T16:35:23.217 に答える