段階的詳細化を使用してDFDを開発する

  • データフロー図 (DFDS)は、システムを通過する情報の流れを表します。DFDは、ソフトウェアシステムプロセスに関連する主要なステップとデータを視覚化するための一般的な方法になりました。

    データフロー図(DFD)は、プロセスまたはシステム(通常は情報システム)のデータのフローを表す方法です。次に例を示します。

    • データはどこから来るのですか?
    • どこへ行くの?
    • どのように保存されますか?

    つまり、トップダウン分解手法(または段階的詳細化として知られている)を使用して、入力と出力の観点からデータがシステムによってどのように処理されるかを示します。

    段階的詳細化とは何ですか?

    複雑な問題を解決する効果的な方法の1つは、それをより単純なサブ問題に分解することです。まず、タスク全体をより単純な部分に分割します。

    ステップバイステップの改良は、本質的にシステムを分解して、システムを構成するサブシステムへの洞察を得ることであり、トップダウン分解法として知られています。

    たとえば、システムの概要は 、サブシステムの任意のレベルを指定するが指定しないシステムコンテキスト図 として作成されます。次に、これらの各サブシステムは、仕様全体が基本要素に縮小されるまで、多くの追加サブシステムレベルで、より詳細に(DFDのレベル0、1、2など)洗練されます。

    よくあることですが、ブレインストーミングの結果、さまざまなレベルの「詳細」なアイデア(実際には、やることリストの内容)が生まれました。その中には、他のアイデアよりも「低い」ものもあれば、含まれているものもあります。その他。

    これらを階層的に配置しましょう。つまり、どのステップが別のステップの一部であるかを特定しましょう。これを行う1つの方法は、各アクションを一連のアクションと考えることです。

    段階的詳細化の例

    きれいな家

    {真空ダイニングルーム、片付けのリビングルーム}

    料理

    {レシピを選択し、材料を購入し、ローストチキン。野菜をやる}

    セットテーブル

    {テーブルクロスを探す、お皿を出す、ガラス製品を出す、銀器を出す、ナプキン}

    ローストチキン

    {オーブンを 400に 予熱し、鶏肉を鍋に入れ、鶏肉を 400 オーブンに 90 分間置きます}

    野菜をする

    {野菜を刻む、野菜を調理する}

    (*出典: トップダウン設計と段階的改良— Wikiブック

    これらの基本的な要素が特定されたら、それらをコンピューターモジュールに組み込むことができます。それらが構築されたら、それらをまとめて、これらの個々のコンポーネントからシステム全体を作成できます。

    DFDのトップダウン分解手法

    DFDでは、 トップダウン分解 (レベリングまたは段階的詳細化とも呼ばれます)は、下位レベルのDFDでより詳細な情報を表示するために使用される手法です。レベリングは、必要な詳細度に達するまで、一連のますます詳細な図を描画することによって行われます。図に示すように、DFDレベリングは、最初にターゲットシステムを単一のプロセスとして表示し、次にすべてのプロセスが機能プリミティブになるまで詳細を表示します。

    • より高いレベルのDFDは詳細度が低い
    • 高レベルのDFDは、低レベルでより詳細なDFDに分解されます。
    • コンテキスト図は階層の中で最も高いものです(DFD作成ルールを参照)。いわゆるゼロレベルの後には、プロセス番号付け(EG、プロセス1、プロセス2)から始まるDFD0が続きます。
    • 次では、いわゆる第1レベル— DFD 1 —番号付けが続きます。EGプロセス1は、DFDの最初の3つのレベルに分けられ、1.1、1.2、および1.3の番号が付けられています。
    • 同様に、第2レベル(DFD 2)のプロセスには、EG 1.1.1、1.1.2、1.1.3、および1.1.4の番号が付けられています。
    • レベルの数は、モデルシステムのサイズによって異なります。レベル0の各プロセスは、同じ数の分解レベルを持たない場合があります。

    DFDの例—カスタマーサービスシステムの例

    データフロー図は、以下で構成される図の階層です。

    1. コンテキスト図(概念的にはレベルゼロ)
    2. レベル1DFD
    3. また、システムの複雑さに応じて、可能なレベル2DFDおよびさらなるレベルの機能分解

    コンテキストDFD

    次の図は、鉄道会社の顧客サービスシステム用に描画されたコンテキストデータフロー図を示しています。これには、モデル化するシステム(この場合は「 CSシステム」 )を表すプロセス(形状)が含まれています。また、外部エンティティと呼ばれる、システムと対話する参加者も表示されます。この例では、  CSAssistant と Passenger がシステムと対話する2つのエンティティです。プロセスと外部エンティティの間には、エンティティとシステム間の情報交換の存在を示すデータフロー(コネクタ)があります。

    このYourdonand CoadDFDの例を編集する

    コンテキストDFDは、データフローモデルの入り口です。プロセスは1つだけで、データストアは表示されません。

    レベル1DFD

    次の図は、レベル1のDFDを示しています。これは、コンテキストDFDに示されているCSシステムプロセスの分解(つまり、内訳)です。図を読んでから、この図に基づいたいくつかの重要な概念を紹介します。

    このYourdonとCoadの図の例を編集する

    CSシステムのデータフロー図の例には、4つのプロセス、2つの外部エンティティ、および4つのデータストアが含まれています。データフロー図での形状の配置を管理する設計ガイドラインはありませんが、理解しやすいように、プロセスを中央に配置し、データストアと外部エンティティを側面に配置する傾向があります。

    この図に基づいて、 乗客はInquiry Transport Details プロセス  から 輸送の詳細 を受け取ることができ 、詳細はデータストアのTransportDetails と RailwayLiveStatisticによって提供されます。Transport Detailsに保存された  データは永続データ(ラベル「D」で示されます)ですが、  Railway Live Statisticに保存された データは短時間保持される一時データです(ラベル「T」で示されます)。コールアウト形状は、乗客が問い合わせることができる詳細の種類をリストするために使用されます。

    CS Assistantは、お土産 の購入プロセスを開始でき  ます。これにより、 注文の詳細が注文 データストア に保存され ます。お土産を買うのは実在の顧客ですが  、注文内容を保存するためにシステムにアクセスするのはCSアシスタントです。したがって、  CSアシスタント から お土産の購入 プロセスへのデータフローを作成します。

    CS Assistantは、注文の詳細を 提供することで チケット の購入プロセスを開始することもでき 、詳細は注文 データストア に再度保存され ます。データフロー図は、高度な抽象化で描画される高レベルの図です。ここで描画されるデータストアOrderは、必ずしも実際の注文データベースまたはデータベース内の注文テーブルを意味するわけではありません。注文の詳細を物理的に保存する方法は、後でシステムを実装するときに決定されます。

    最後に、  CS Assistantは、インシデントとアイテムの詳細を提供することで紛失レポート プロセス  を開始でき 、情報は紛失アイテム データベース に保存され ます。

    例によるDFDの詳細

コメントを残す

メールアドレスが公開されることはありません。