質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
MySQL

MySQL(マイエスキューエル)は、TCX DataKonsultAB社などが開発するRDBMS(リレーショナルデータベースの管理システム)です。世界で最も人気の高いシステムで、オープンソースで開発されています。MySQLデータベースサーバは、高速性と信頼性があり、Linux、UNIX、Windowsなどの複数のプラットフォームで動作することができます。

Q&A

解決済

5回答

22297閲覧

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

samuraiders

総合スコア63

MySQL

MySQL(マイエスキューエル)は、TCX DataKonsultAB社などが開発するRDBMS(リレーショナルデータベースの管理システム)です。世界で最も人気の高いシステムで、オープンソースで開発されています。MySQLデータベースサーバは、高速性と信頼性があり、Linux、UNIX、Windowsなどの複数のプラットフォームで動作することができます。

0グッド

2クリップ

投稿2016/06/08 08:25

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

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

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

###作成したフローチャート
イメージ説明

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

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答5

0

ベストアンサー

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

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

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

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

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

以上、ご参考まで

投稿2016/06/08 15:26

takito

総合スコア3111

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

samuraiders

2016/06/09 00:28

ご回答頂きありがとうございます。 恥ずかしい話なですが、UML自体が初めてでどのツールを使っていいのかも判断つかないままフローチャート図を使用しておりました。 違和感があるものを分解して記載し、シーケンス図を利用した方法も試してみてどちらが適しているか・使いやすいかを試してみます。
guest

0

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

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


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

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

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

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

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

投稿2016/06/08 10:32

KiyoshiMotoki

総合スコア4791

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

samuraiders

2016/06/08 12:55

ご回答頂きありがとうございます。 矢印を点線にしてみること等も考え、自身のチーム内だけで使うということであればそれでも問題ないと思います。 しかし、今後のため正しいフローチャートの記述法を身につけようと思い質問させて頂きました。 また、質問とは別視点でのご意見も頂きありがとうございます。 "このステータス更新を行なう主体が誰なのか、分かりません。" →仰るとおり、何がキッカケで更新が行われるか見えませんね。  OKであれば更新ということを表したかったのですが。。 ”ここで再びステータスを"入庫"に更新しているため、フローが何かおかしい気がする。” →これは矢印を持っていく場所がおかしいですね。修正致します。 ”ご提示のフローだと、いったん出庫したものしか廃棄できないことになる。” →基本的にはその考え方で問題ないのですが(不良品は修理という扱い)イレギュラーも有り得ますので再考致します。
guest

0

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

投稿2016/06/08 08:46

rifuch

総合スコア1901

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

samuraiders

2016/06/08 12:57

ご回答頂きありがとうございます。 シンプルに表現するためにDBを一つにして更新処理をそこに集約しておりましたが、やはりDBへの更新処理が発生する都度記載したほうがわかりやすですね。書き直したものを再度アップしてみます。 ”ステータス更新の処理は一つのブロックの内部で完結しているとして、矢印を書く必要は無いのではないでしょうか?” 初心者で申し訳ないのですが、こちらのコメントに関しまして理解ができておりません。 詳しく教えて頂けると幸いです。
rifuch

2016/06/08 13:38

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

2016/06/09 00:20

コメントありがとうございます。 確かに粒度を荒くしても、そこに説明等が記載されていれば理解できると思うので、その方法で記載してみます。 フローチャートは現場では使う機会が少ないんですね。 今回は、自分自身の理解とチームへの説明のためのツールに役立つと思いトライしてみました。 その他のツールについても状況に応じてトライしてみたいと思います。
rifuch

2016/06/09 02:12

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

2016/06/09 02:41 編集

コメントありがとうございます。 回答頂いた中から自分の中で一番落とし込めた内容を自己解決として投稿しました。 今回の経験を通し、UMLについて色々調べた結果、粒度順として以下が正しいかな?と考えています。 ユースケース図 > シーケンス図 > フローチャート図(アクティビティ図) 粒度という言葉が適しているかはわかりませんが、左にいくほど全体像を表現できる一方、右にいくほどより細い表現ができるものと考えております。 今回は「処理に応じてDBのあるステータスを変更する」という部分に特化したかったため、フローチャート図で表現するのが正しいのでは?と判断致しました。
guest

0

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

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

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

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

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

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

投稿2016/06/09 02:35

samuraiders

総合スコア63

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

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

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

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

投稿2016/06/08 12:40

HogeAnimalLover

総合スコア4830

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

samuraiders

2016/06/08 12:49

ご回答頂きありがとうございます。 もともとフローチャートなどのアウトプットはやったことがなく、仰るとおり自分自身でプログラムを行う場合は直接書くことも可能ですが、自分自身の理解とチームへの説明のためのツールに役立つと思いトライしてみました。 教えて頂いたデータフローダイアログについても調べてみます。 ちなみに、開発言語はPHPです。
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問