2009-08-30 3 views
7

私のプログラムのロジックをダイアグラムで表現したいのは、プログラムがかなり複雑だからです。私は別の人に、なぜ、私のプログラムで何が起こるかを説明する方法が必要です。フローチャートは唯一のオプションですか?プログラムロジックのビジュアル表現

答えて

2

ステップバイステップで説明する必要がある場合は、フローチャートが必要です。より高いレベルで話すことができる場合、別のオプションは状態図である可能性があります。

http://en.wikipedia.org/wiki/State_diagram

4

フローチャートは、人気のある選択肢であり、しばしば非技術的な人々のために適しています。

状況をより技術的に把握したい場合は、UMLを使用する方がよいでしょう。

A sequence diagramは、コンポーネント同士の相互作用を示しています。

+0

ユースケース図もあります。しかし、この質問に基づいて、私は同意します - フローチャートが私の最初の選択です。 – TrueWill

10

UMLでは、さまざまな図が、さまざまな方法論を使用して、さまざまなことを意図しています。オブジェクト指向メソドロジに頼る傾向があることを考慮して、さまざまな図とその仕組みを説明します。

  • ユースケース図 - ユースケースモデルのポイントは、システムがサポートしなければならない基本的なビジネスプロセスのすべてを識別して定義することです。これは、ユーザーとシステムの両方の視点からのものです。ユースケースでは、システム内の任意のアクションを使用できます。これにより、さらに説明モデルを使用できます。

  • アクティビティ図 - これは、ユースケース図の内容を説明するためのワークフロー図の一種です。基本的には、アクティビティのフロー、または複数のアクティビティを記述する視覚的な方法です。

  • シーケンス図 - これは、システム内またはプロセス内のさまざまなオブジェクト間の通信を示す図です。シーケンス図は、詳細なシステム設計とユーザーインターフェイス設計にとって重要なものとなるため、分析において重要です。システムで何が起きているのかを素晴らしい視点で伝えているので、私はこれらが本当に好きです。

  • ステートマシンダイアグラム - これにより、オブジェクトの存続期間中のオブジェクトの状態を追跡することができます。これにより、オブジェクトがどのように動作するかについての大きな洞察が得られます。これにより、システム内でイベントなどを効果的にマッピングする方法が得られます。上記の図を使用して

は、分析と設計のための偉大な基礎を与え、そして1はこれらの図が作成されると、彼らは必ずしも完全ではないことに注意すべきです。設計プロセスでは、システムが進化するにつれてこれらの図を変更します。これがあなたに役立つことを願っています以下は、言及された様々な図のためのウィキペディアへのリンクです。すべてのプログラムの後ろ

Use Case Diagram

Activity Diagram

Sequence Diagram

State Machine Diagram

2

問題のおそらくセットがよくドメイン精通のグループによって理解された問題領域であります問題解決のための方法が収集され、その問題を処理するために使用されるソリューション・ドメインが含まれます。

何かを説明するには、最初に問題のドメインに同意する必要があります。あなたの問題のドメインが信号処理であり、説明がドメインに精通していない誰かに行くなら、あなたはすでに乾杯しています。

解決策ドメインを説明する(または技術ハンドブックに記載されているようによく知られている解決策のセットを参照する)必要があるため、この特定の問題に適した特定のソリューションを正当化できます。答えに置くことができる他の制約(小さなマシンで実行され、1日で構築されるなど)。あなたが説明している人が、選択した信号処理領域の問題に対する可能な解決策として、高速フーリエ変換を理解していない場合は、ソリューションのエクスパンションを行うことはできません。選択肢。

この2つの障害に合格すると、のいずれかのフローチャートが役立つかもしれません。様々なタイプのUMLダイアグラムのような他の松葉杖はすべて、さまざまな視点からソリューションの構造を説明しています。どのような観点の問題は、説明の目的が何であるかに依存します。

フローチャートについて:アルゴリズムが記述されていたのは一般的ですが、擬似コードでは一般的に十分です。擬似コードに従うことができない人々は、大きな流れ図に従う可能性は低い。あなたのフローチャートが簡単なものであれば、それは必要ありません。私は20年で真剣に1つを使用していない。コンピュータサイエンスの文献のほとんどはそれを使用していないようです。

特に、自動プログラム分析の目的で実際のコードが何をしているのかをきわめて細かく理解したいときは、フロー・チャート(「制御フロー」という名の下にあります)は依然としてかなり有用です。 a COBOL control flow graph(およびthis for an explanationを参照)を参照してください。他の人にアルゴリズムを説明するためにこれを使用したくないことは明らかです。

関連する問題