どのように私は私達の会社のソフトウェアのいずれかでファイルの読み込みプロセスを調査するタスクを持っている

Question

ソフトウェア製品のワークフローを表現するために、私が書くようやく仕事のどのような点で行われ、メインクラスとメソッドとを表すとする必要がありますある種のダイアグラムでそれについて報告してください。

このワークフローをテキスト文書を記述するか、UMLを使用して記述し、どの種類の図を使用すればよいでしょうか。

Answer 1

使用UMLアクティビティ図（http://www.agilemodeling.com/style/activityDiagram.htm）。そして

、さらに詳細を保証するのに十分複雑な部分についてUMLのシーケンス図（http://www.agilemodeling.com/artifacts/sequenceDiagram.htm）を使用します。

Answer 2

すべてのドキュメントの最適なフォーマットは、それが運ぶ情報だけでなく、対象とするオーディエンスによっても異なります。あなたの聴衆がソフトウェアエンジニアで構成されているなら、私はUMLが良い選択だと言うでしょう。標準化されているので、独自の表記法を説明したり説明したりする必要がなくなり、 UMLの専門家がいなくても、あなたの読者はそれらを読むことができます。

あなたはドキュメントが何のためにあるのか言うことはありませんが、最低でも、私はあなたのレポートの次のセクションを示唆している：

ソースビュー]：クラス図を、おそらくいくつかのパッケージ図と同様に応じて、実装言語、パッケージの数と種類（パッケージがJavaでできるような機能抽象化を提供する場合は、それらを記述することを検討してください;それ以外の場合はそれほど重要ではありません）。

ランタイムビュー：少なくとも主要機能の制御の流れを記述するシーケンス図。

またこれらの一つ以上を追加することを検討可能性があります

全体的な設計：ソフトウェアの主要な部分について説明コンポーネント図：インスタンスDLLとユーザーのコードによって呼び出されるAPIのために（私たちを想定何らかのライブラリルーチンについて話している）。これは、特定のメソッド呼び出しや実装クラスに関係するものではなく、ソフトウェアを高いレベルで記述します。

概念図：これは、主に非常に単純なクラス図を使用して、重要な概念を説明する必要があります。 （... EOF、閉じて、開いている）ファイルは、おそらく、このような一つであり、あなたは、ファイルの異なる状態を記述するステートチャートを含めることを検討すべきです。

（コードを生成するのではなく、例えば）ドキュメントためにUMLを使用する場合にいつものように、各図中のノートと寛大な、および要素（クラスなど）を備えた疎です。テキスト文書に貼り付けるための図については、各図に半ダース以上の要素を入れないようにしています。高レベルの処理の流れのため