フローチャート図の書き方

Question

###前提・実現したいこと
現在フローチャートを勉強しており、以下の記載方法がわからないため質問致します。

###発生している問題
処理に応じてDBのあるステータスを変更するフローチャート図を作成したのですが、添付の様な記載方法となってしまい、一つの処理に対し矢印が複数方向に対し向いていることに違和感を感じております。

正しい記載方法を教えて頂けると助かります。

###作成したフローチャート

よろしくお願い致します。

Answer 1

フローチャートは、言葉がしめすように「処理の流れ」を図で表現するものなので、データベースとの関係性を表現するのは不向きと思います

どうしてもデータベースの絵を入れて表現したいのであれば、書かれた絵でも別にかまわないと思いますが、私なら「在庫マスタを更新する（STS=＊＊＊）」という処理を書くと思います

特に違和感があるのは、「受入試験」「出荷試験」の条件分岐で右向きにsts更新の矢印が出ている部分ですね
条件分岐（ひし形）はプログラミングの「ＩＦ文」に相当します
条件によって処理の方向が変わることを表現する記号なので、「処理」を一緒に表現するのはおかしいです

「受入試験」の部分であれば
１）「受入試験を行う」（処理）
２）「在庫マスタのstsを【受入試験中】にする」（処理）
３）「試験結果を判定し、ＯＫなら＊＊へ、ＮＧなら＊＊へ（条件分岐）
という３つの手順に分解した方が、図が多少長くなっても処理が１つ１つが表現され網羅されるので、フローチャートを見た人により伝わりやすくなるかと思います

ちなみに、時間軸に沿って処理タイミングごとにＤＢや他処理部との関係性を表現する図では、ＵＭＬの「シーケンス図」というのがあります
私はこの図が大好きで、人への説明でよく使います

以上、ご参考まで

Comments

[samuraiders]

ご回答頂きありがとうございます。

恥ずかしい話なですが、UML自体が初めてでどのツールを使っていいのかも判断つかないままフローチャート図を使用しておりました。

違和感があるものを分解して記載し、シーケンス図を利用した方法も試してみてどちらが適しているか・使いやすいかを試してみます。

Answer 2

処理フローとしての矢印とステータス更新を表す矢印（「在庫マスタ」に向いている矢印のこと）が同じように見えることが、違和感の原因だと思います。

ステータス更新を表す矢印を点線にするなどして別の意味であることを分かりやすくするか、
rifuch様の回答にあるように、ステータス更新を矢印で表さないようにすれば、違和感は解消するかもしれません。

---

以下は私が感じた、ご質問とは別の違和感です。
見当違いな意見であれば、お読み捨てください。

• "受け入れ試験"と"引当て"の間、および"出荷前試験"と"出庫"の間の矢印から、ステータス更新の矢印が伸びている
  -> このステータス更新を行なう主体が誰なのか、分かりません。

• 出荷前試験でNGになった場合の処理が不明
  -> まだ書いている途中？

• "返却"でステータスを"入庫"に更新していながら、"再利用"が yes だった際に再び"入庫"処理に移行している
  -> ここで再びステータスを"入庫"に更新しているため、フローが何かおかしい気がする。

• ご提示のフローだと、いったん出庫したものしか廃棄できないことになる。

Comments

[samuraiders]

ご回答頂きありがとうございます。

矢印を点線にしてみること等も考え、自身のチーム内だけで使うということであればそれでも問題ないと思います。
しかし、今後のため正しいフローチャートの記述法を身につけようと思い質問させて頂きました。

また、質問とは別視点でのご意見も頂きありがとうございます。

"このステータス更新を行なう主体が誰なのか、分かりません。"
→仰るとおり、何がキッカケで更新が行われるか見えませんね。
　OKであれば更新ということを表したかったのですが。。

”ここで再びステータスを"入庫"に更新しているため、フローが何かおかしい気がする。”
→これは矢印を持っていく場所がおかしいですね。修正致します。

”ご提示のフローだと、いったん出庫したものしか廃棄できないことになる。”
→基本的にはその考え方で問題ないのですが（不良品は修理という扱い）イレギュラーも有り得ますので再考致します。

Answer 3

在庫マスタをエンティティで表現しているのが違和感の原因では?
DB更新処理が一つの処理であれば、
入庫
入庫ステータス更新
のように処理を分ければ矢印は一つになりますし、DBの書き込み失敗のフローも書けます。
共通処理として図上で省略可能なのであれば、ステータス更新の処理は一つのブロックの内部で完結しているとして、矢印を書く必要は無いのではないでしょうか?

Comments

[samuraiders]

ご回答頂きありがとうございます。

シンプルに表現するためにDBを一つにして更新処理をそこに集約しておりましたが、やはりDBへの更新処理が発生する都度記載したほうがわかりやすですね。書き直したものを再度アップしてみます。

”ステータス更新の処理は一つのブロックの内部で完結しているとして、矢印を書く必要は無いのではないでしょうか?”
初心者で申し訳ないのですが、こちらのコメントに関しまして理解ができておりません。
詳しく教えて頂けると幸いです。

[rifuch]

ええと、ブロックの粒度の話です。
ブロックの粒度を荒くするならば、そのブロックの内部にさらに詳細なフローが隠れている、という考え方です。
つまり、「入庫」の処理の中に、DBへの更新処理が入ってしまっているのであれば、一つのブロックで表現しても問題ないのではないかという事です。
さらに詳細なものが必要なら、一つ一つのブロックの処理を別の図で表すとか。
実際、実務ではフローチャート自体を書く事がない(クラス図や状態遷移図、シーケンス図は書きますが)ので、どの程度の粒度が適切かというのは、あまり役に立てないかもしれません。

[samuraiders]

コメントありがとうございます。

確かに粒度を荒くしても、そこに説明等が記載されていれば理解できると思うので、その方法で記載してみます。

フローチャートは現場では使う機会が少ないんですね。
今回は、自分自身の理解とチームへの説明のためのツールに役立つと思いトライしてみました。
その他のツールについても状況に応じてトライしてみたいと思います。

[rifuch]

作成するものによっていろいろかと思いますが、基本的に全体の理解をさせたいときはユースケース図を使います。
ほとんどの場合、クラス図かER図は書きます。
外部通信が関わってきて、やりとりのタイミングがわかりにくいときはシーケンス図を書きますし、オブジェクト状態についてわかりにくいときは状態遷移図を書いたりもしますが、多くの場合は書きませんね。
ほとんどの場合、自分自身の理解のために作図しますが、チームメンバーの理解度などによって粒度やどの図を用意するかはまちまちです。
場合によっては、文章で書く方が早い事もありますし。
適材適所なので、色々使いこなせると便利ではあるので、UMLは押さえておいても損はないと思います。

[samuraiders]

コメントありがとうございます。

回答頂いた中から自分の中で一番落とし込めた内容を自己解決として投稿しました。

今回の経験を通し、UMLについて色々調べた結果、粒度順として以下が正しいかな？と考えています。

ユースケース図　＞　シーケンス図　＞　フローチャート図（アクティビティ図）

粒度という言葉が適しているかはわかりませんが、左にいくほど全体像を表現できる一方、右にいくほどより細い表現ができるものと考えております。

今回は「処理に応じてDBのあるステータスを変更する」という部分に特化したかったため、フローチャート図で表現するのが正しいのでは？と判断致しました。

Answer 4

ご回答頂いた皆様、ありがとうございました。

頂いた意見の中から、今回は処理一つ一つを分解し、矢印が分散しないように対応したいと思います。
処理が多くなり見づらくなってしまった場合は、粒度を荒くし一つの処理の中でDB更新もあることを記載して対応してみます。

いくつかの回答からフローチャート図が適しているのではないかとあったので試しに書いてみましたが、より多くの処理を記述する必要がある（勉強不足のせいでそう感じただけかもしれませんが。。）と思い、今回の目的である「処理に応じてDBのあるステータスを変更する」という部分にフォーカスした場合フローチャートの方が適しているのでは？と判断しました。

今回の経験でUMLをより習得したいと思いましたので、今後も勉強を続けてまいります。

ベストアンサーにつきましては、解決策を提案頂き且つ最も自分の中で落とし込めたものを選択しております。
それ以外の方から頂いた回答につきましても、大変参考になりました。

この場をかりてお礼申し上げます。

Answer 5

フローチャートは万能ではありません。例えば並列処理を図示することは不可能です。本件の図示であれば、データフローダイアログを先に作っておくことが一考だと思います。

ちなみに、使用言語がC言語等の手続き型ならば、フローチャートを作ることができる段階までプログラムを整理できているならば直接ソースコードを書き下すことができる場合も少なくないです。最近は開発環境も整っているのでフローチャートはあまり使わなくなってきている傾向が見られます。（ソースの説明のためにフローチャートを作ることはありますが、本末転倒なので釈然としないと思っています。）

フローチャートよりも前段階のグラフづくりも軽視できません。

Comments

[samuraiders]

ご回答頂きありがとうございます。

もともとフローチャートなどのアウトプットはやったことがなく、仰るとおり自分自身でプログラムを行う場合は直接書くことも可能ですが、自分自身の理解とチームへの説明のためのツールに役立つと思いトライしてみました。

教えて頂いたデータフローダイアログについても調べてみます。

ちなみに、開発言語はPHPです。