C++ではフローチャートを使わない理由

「オブジェクト指向言語ではフローは書かない」理由を教えてください

書かないのは、「書かなくても良い」くらい処理を単純化することが、オブジェクト指向プログラミングの基本精神だからです。

したがって「書いてはいけない」わけでもなく、「書く必要がないような設計にする」あるいは「書かなければならないほど複雑な論理にしない」と云うくらいが適切だと思います。

◇関数(＝メソッド)内部の処理を設計する際にどのような手法を用いるのか

オブジェクト指向プログラミングでは、１つのメソッドが１つの機能だけを提供するように設計することが推奨されます。

無用な複雑化を避けるためです。

そのために、クラスの提供するサービスをどのように各メソッドに分割するか、汎用性（再利用性）と保守性にも気を配りつつ検討することになります。

上手に機能分割できれば、各メソッドの内部処理も通常は単純なものになります。

もちろん単一の機能が非常に複雑な処理を要求する場合もあります。

たとえば、暗号/復号などの数学的に複雑な処理や、大規模なソートなどは、単一機能ですが処理は複雑です。

このような複雑なアルゴリズムを表現するために、フローチャートなどの図表を用いるのは特段おかしな事ではありません。

※ メソッドの実装はプログラマ任せ、という場合ももちろん有ると思いますが、個人の趣味プログラムでもない限り保守を他人が担当する場合を考え、複雑なアルゴリズムの文書化は必須です。ただ設計の拙さを文書で補うなどは論外ですが。

◇設計工程のアウトプットとしてどのようなダイアグラム(図表)で表すのか

通常はUMLで定義される図表を使います。

オブジェクト指向設計のアウトプットは、各メソッドの内部の構造よりも、提供するサービスを担うクラス間の関係を明確にする必要性が高くなります。

UMLはそのために考案された図表を規格化したものです。

現在１３種の図表が定義されていますので、目的に合わせてその中から必要なものを取捨選択して利用します。

◇評価項目抽出におけるインプットはなにになるのか

ここでs_dekuasさんの云われている「評価項目」が具体的に何を指されたものか、ちょっと迷うのですが、設計の妥当性を評価するための項目ということでしょうか。

上記の前提では、ユーザからの要求仕様ということになります。

もっともこれは、オブジェクト指向プログラミングに限ったことではありません。

なお現在ではユーザの要求仕様を的確かつ迅速に汲み取ることの重要性が強く認識されていますので、そのための手法も各種提案されています。

オブジェクト指向分析・設計とセットでよく取り上げられるのは、ユースケースによる分析です。

システムに要求される機能要件及び非機能要件（性能やUIなどのイメージ）を、ユーザとのヒアリングを通じてユーザの言葉で語ってもらい、それをシステム運用の「シナリオ」という形にまとめて、ユーザに理解できるレベルで要求仕様を固めていく手法です。