データフローダイアグラムではプロセスは一番最後に書く
データフローダイアグラムの書き方について、良い記事があったのでリンクしておく。
記事を読んで、まだ修行が足りないと感じたので、自分用のメモ。
【参考1】
データフローダイアグラムの書き方
(引用開始)
プロセス,データの発生源・行き先,データの保管元・保管先全てに名前がついているにもかかわらず,データの流れにだけ名前がついていないDFDを見かけることがあります.
これらはDFDの役割を果たしていません.
DFDが表現しなければならないのは,プロセス,データの発生源・行き先,データの保管元・保管先を行き来するデータなのです.
データの流れに名前をつけないのは,DFDが最も表現しなければならないものを表現していないということです.
図6.プロセス名は最後につける
(引用終了)
(引用開始)
入出力するデータからプロセスの内容の推測が困難な場合,原因はプロセスの機能分割が適切ではないことが多々あります.
プロセスは,例え名前がなくても,入出力データからその内容を容易に推測できるものでなくてはなりません.
データの流れに名前をつける際には,「~情報」や「~データ」と言う名前をつけてはいけません.
抽象的すぎ何を表わしているのかわかりません.
図6の営業所からのデータの流れの名前が「販売実績」ではなく「営業所情報」や「販売情報」だったら,何を表わしているのかわかるでしょうか.
もし,データの流れに具体的な名前がつけられないのなら,DFDの作り方に間違いがあります.再検討しましょう.
(引用終了)
【参考2】
DFD(データフローダイヤグラム)の描き方(1) | ステキな一日
(引用開始)
仕事でDFDを書く機会が多いのだが、DFDの書き方を知らない人が多いのでここにメモしておく。
自分自身が100%完璧に使いこなしているわけではないので、自分の理解している範囲での内容となる。
データフローダイヤグラム(DFD)は単独で成り立つものではありません。
データディクショナリーとミニ仕様書という三点セットで業務分析を行う際に使用します。
システムの概念だけを伝えるのであれば、DFD単体でも良いのかも知れませんが・・・。
(引用終了)
DFD(データフローダイヤグラム)の描き方(2) | ステキな一日
(引用開始)
さて、DFDの描き方です。一番初めに何を描きますか?
(1)今回の対象外となるものをすべて描き出します。
これは外部要素となるものです。それは取引先だったり、外部システムだったりします。
(2)そして外部要素への入出力を描きます。(これは対象外への最終的な入出力となります。)
(3)データフロー名は必ず書くようにしてください。
プロセス名を入れたいかも知れませんがプロセス名は無くても大丈夫です。(後で入れられるし、変わるかもしれないので)
(4)今度はデータフローをよく見ていきます。
足りないデータフローがたくさんあるはずですから、図にどんどんデータフローを足していきます。
また、データフローが変換されるところや複数に分岐するところにはプロセスも足していきます。
そうやってどんどん書き足していくと、データを保管する所も見えてきますのでデータストアも書き足していきます。
そうやって、描き替えながらユーザとどんどん対話してください。
(引用終了)
DFD(データフローダイヤグラム)の描き方(3) | ステキな一日
(引用開始)
DFDを書くうえで一番重要なのがデータフローの名前の付け方です。
データフロー名の付け方によってDFDの分かりやすさはかなり違ってきます。
ここが一番肝心かなめのところですから手を抜かないようにしてください。
プロセスに名前を付ける段階ではデータフローのすべてに名前が付いてなければいけません。
はじめにプロセスに名前を付けたいかもしれませんが、ぐっと我慢をしてください。
プロセスに最後に名前を付けるのは、データフローを正しく書くために必要です。
(中略)
プロセスに先に名前を付けてしまうと、DFDを書けてしまった気になって肝心のデータフローがおろそかになったり、分析が足らなかったりしますので、注意してください。
(中略)
エクセルの図形で描いてもいいのですが、それでは書き直しが面倒になってきて、かなり出来の悪いDFDしか書けないと思いますのであまりおすすめできません。
それよりは手書きの方がマシだし、それともVISIOでも良いです。
個人的にいちばんおすすめなのが astah* professional というソフトウェアです。
(引用終了)
DFD(データフローダイヤグラム)の描き方(4) | ステキな一日
(引用開始)
DFDにセットで必要になるものがあります。それがデータディクショナリーとミニ仕様書です。
データディクショナリーには、データフローの内訳を記述します。
そして、ミニ仕様書にはプロセスの内容を記述します。DFD、データディクショナリー、ミニ仕様書が揃ってひと塊となります。
どれが欠けても中途半端です。
(中略)
しかしながら、これもまた、DFD、データディクショナリー、ミニ仕様書を行ったり来たりしながら、ブラッシュアップさせていくものです。
(引用終了)
DFD(データフローダイヤグラム)は業務システム設計でよく使うけれど、何故か描きにくい、と思う時が多かった。
缶アイコンのデータストアは書けるのだが、プロセスがイマイチしっくりこない時が多い。
上記の記事を読んで、プロセスを最初に書いてしまうので、それに引きずられて、本来のモデルが描けなくなっているのではないか、と気づいた。
「プロセスの名前は一番最後に書く」。
つまり、外部要素やデータフローをじっくり書き込んで、漏れを無くし、整合性を取った後で、最後にプロセスの名前を書けばよい。
DOAでは、データが主であり、プロセスは従の立場だから。
プロセスは最後に名前付けすることで、データの入出力やタイミングに集中して分析できるようになる。
これから気をつけようと思う。
| 固定リンク
「モデリング」カテゴリの記事
- 「システム開発・刷新のためのデータモデル大全」を読み直した感想~親子頻出アンチパターンは初心者モデラーに多い(2024.08.31)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- アーキテクチャ量子の考え方はソフトウェア工学に物理学アプローチを適用したアイデアではないか(2024.02.12)
「astahによるUMLモデリング」カテゴリの記事
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
- astahにタイミング図がサポートされた(2024.03.12)
- 概念モデリングや設計原則は進化しているのか(2023.10.21)
- パッケージ原則とクラス原則の違いは何なのか(2023.10.14)
コメント