[ソフトウェア設計]処理の流れは、アクティビティ図？フローチャート？どちらで書くべきか。

質問

VCですでに組まれているソフトの設計を設計書として文書にする作業をしています。
（現状あるソフト設計を別のソフトの設計に継承するため、このような作業が発生しました。すでに組まれているソフトには設計書がありませんので、参照はできません。）
この場合、ソースコードに記載されている処理の流れは、UMLのアクティビティ図で書けるのでしょうか？
参考書でアクティブ図を勉強しましたが、プログラムの処理の流れ（基本情報技術者試験の擬似言語で記載されているような処理）をそのまま書いたような図は見つかりませんでした。一般的には、プログラムの処理の流れは、アクティブティ図では、書かないのでしょうか？
そのような処理は、フローチャートで書くべきなのでしょうか？
シーケンス図も一緒に書いていますので、できたらUMLで統一し、アクティブティ図で書きたいのです。
設計書は、今まで記載していなかったので、ノウハウがありません。
知識がおありの方がおられましたら、ご教授お願いいたします。

回答No.2

MrBan · ベストアンサー

そのレベルの処理フローは、UML的にはシーケンス図で表現するものだとは思いますが、それはもう書かれているのですよね。

普通、アクティビティ図で書くのは、普通もう少し上流のフローかと。アクティビティ図でも書けなくはないと思いますが、書きにくいと思います。

あえてUMLで書くなら、コミュニケーション図(UML1.xだとコラボレーション図)が近いでしょうか。
でも、設計がオブジェクト指向的じゃないものをこれにまとめると、分かりにくいんですよね。

いずれにしろ、UMLはオブジェクトが単位にあるので、既存VCのアプリがオブジェクト設計としてダメダメだったりすると、UMLにすること自体がすごい大変かも。

# VC(特にMFC)のアプリはそういうところが目立たなかったりしてたので、似非オブジェクト指向なものも多いのが現実。
# UMLの図と対応できない/しにくいということは、大体はOO的に設計が汚いってことなんですけどね。

そういう場合は、割り切ってフローチャートもやむなしかも。(個人的には不要と思いますが)

そんなものの設計を継承すると、新規の部分もダメ設計になることは見えてるので、根本的に流用元として使うという構想自体が廃案になるのかもしれませんが。

あと、基本情報処理の擬似フローみたいな図って、多分書いてもあんまり意味ないですよ。
それみて分かるような人はソース見ても大体分かりますし、ソースにコメント追加したほうが早いかも…(苦笑
(ソース自体ではなく)設計を流用するということは、もっと大局的な/抽象的なフローが欲しいのでは？
シーケンス図(+ステートチャート図とか)で十分(にならないといけない)気がします。

補足

いろいろ有用な情報をありがとうございます。
シーケンス図には、大局的なオブジェクトの関係とおおまかな処理のフローを書いています。
加えて、納入先から大局的な設計だけでなくて、処理がややこしいと思われる箇所はプログラマーがどのような処理を書けばいいかもわかるような設計をしてほしいという要求がでているので、大局的な設計に加え、細かな処理フォローも必要となっています。
しかも、納入元が設計方針として、「納期短縮最優先。現状ソフトの処理で使える箇所があり、それを使った方が納期短縮できるなら、設計がよろしくなくとも使うこと」となっています。（今度作成するソフトはバージョンアップはしないので、再利用できる設計に変更などには特に時間をかける必要はないらしいです。）
シーケンス図は、あまり細かな処理フローを書くには適していないですよね？
今回書きたいフローは、オブジェクト間の関係ではなく、オブジェクトの中身の一部の処理に関してなので、いろいろ聞いてると、フォローチャートがいいのかなって感じました。
いろいろな有用な情報、ありがとうございました。

回答No.3

a-saitoh

設計書の納入先に、どういう図式がよいか問い合わせるのが善くはないですか?
えり好み(社内規定)のある会社も存在しますし。

お礼

納入先は、どうのような図式で書くかということを含めて弊社に任せています。
社内でも今まで設計書なるものを書いている例がほどんどなく、ノウハウがない状態なんです。
納入先にもソフト担当者はいるのですが、設計書のノウハウはなく、いろいろ調べて書いてくださいって感じです。
アドバイスありがとうございます。

回答No.1

tadys

フローチャートは諸悪の根源です。
相手によっては笑いものにされたり馬鹿にされたりします。

私は出来上がったソフトをソフトを知らない素人に説明するときにフローチャートを書くことはありますが、設計の為にフローチャートを書くことはしません。

ただし、フローチャートを元に製作されたソフトはフローチャートで無いと表現できない場合もありえます。
その場合はしょうがないですね。

参考URL：

http://www.pro.or.jp/~fuji/mybooks/cdiag/cdiag.3.3.html

お礼

オブジェクト間の関係ではなく、オブジェクト内の一部の処理に関してのフローを書かなくてはならないのです。
今回できあがったソフトの処理を文書として書くだけの作業ですので、フローチャートがいいのかなと思いました。
フローチャートはあまりよくないんですね。知らなかったです。今後はそのようなことを踏まえて、設計書を記載していきます。
有用な情報をありがとうございました。