疑似コーディングによるソフトウェア設計？

疑似コードに基づく方法でソフトウェアを設計する（つまり、書き留める）良い方法を知っていますか？

私はソフトウェア設計に不慣れで、UMLに関する情報を読んでいます。私の控えめなクラス階層はこれまでのところ良好ですが、複雑になったら、「全体を見る」ことで、将来の拡張性のために別の構造を使用できることに気付きました。Pythonはプロトタイピングに適しているので、書き始めたばかりで大丈夫ですが、まったくそうではありません。

そこで、UMLクラス図を試しましたが、あまり役に立たないようです。そこで解決する問題は、頭の中でささいなことです。しかし、実際のメソッドの疑似コード化を開始すると、追加の設計要件に気づきます。

では、疑似コードで設計したい場合、どうすればよいでしょうか？私にとっては、コードとほぼ1対1の方法が最も効果的だと思います。しかし、ほとんどのUMLソフトウェアはメソッドのコードさえ表示しません（たとえば、GoFの画像とは対照的です）。

誰かがUMLはドキュメンテーションとプレゼンテーションのためだけのものであり、デザインのためにはそれほど優れていないと主張しましたか？私もその感覚を得ます。Envision APDTが見つかるまで、純粋なUMLといくつかの単純化したホワイトボードスケッチがソフトウェアを設計する方法であると思いました。

それで、アジャイル開発は私が注意すべきものですか、それともランダムにそのアジャイルと呼びますか-アジャイルはスケジュールのみに関するものだと思いましたか？または、私は（UMLを使用して）間違って設計していますか-誰かが疑似コードで設計していますか？どうすればそのための優れたツールを見つけることができますか？

 I thought agile is about schedule only?

単なる計画ではありません。アジャイルソフトウェア開発は、進化的開発であり、製品の所有者から要求された変更への柔軟な対応を促進する適応計画を備えた、タイムボックスでの反復配信です。

 Or am I designing incorrectly (with UML) - does anyone design by pseudocode? 

私の経験では、クライアントスタンドの観点から見ると、チャートははるかに理解しやすくなっています。彼らは視覚的に魅力的で、多くの場合非常にカラフルでフォローしやすいです。ただし、実際のアプリケーションコードとの切断の性質上、チャートを維持することは非常に困難です。アプリケーションに変更が加えられるたびに、開発者はチャートを含むすべてのドキュメントを更新するために時間をかけなければなりません。ただし、クライアントのビジネスプロセスをよく理解し、UMLダイアグラムを管理できるBAがチームまたは会社にあれば、その問題は簡単に解消できます。

UMLのようなツールを使用すると、このプロセスが簡単になりますが、オブジェクト指向プログラミングでのみうまく機能します。技術チームにとって疑似コードははるかに簡単です。このコードを作成するプロセスにより、実際のプログラミング言語開発フェーズの速度が大幅に向上します。

あなたが同様に見ることができるいくつかの他の選択肢があります：

• データフロー図
• 状態図
• プロセスフローチャート

見た目の良い参照：ソフトウェア設計のチュートリアル。さらに、PseudocodeまたはCodeに関する優れたブログを読むことを個人的にアドバイスしますか？Coding Horrorによる投稿- 読むための私のお気に入りのブログ:)

全体として、考慮する必要があるいくつかのトレードオフがあります。

アセンブリ言語でプログラミングする場合、疑似コードを書くことは非常に理にかなっています。このアルゴリズムは、手動でアセンブリ言語に翻訳してから翻訳をデバッグする手間をかける前に検証できます。FORTRAN IVのような第1世代のコンパイル済み言語では、一部の制御構文はGOTOであり、すべての変数（仮引数を除く）はグローバルであり、変数名は6文字に制限されていました。

今日、アセンブリ言語でプログラミングを行うことはほとんどありません。コードを記述するだけでなく、疑似コードを記述することにはほとんど価値がありません。まともな言語では、実際のコードは疑似コードのほぼすべての単語をたどります。疑似コードは時間の無駄です。

しかし、私は一番下からコーディングを始めません。私はTDDに従って、テストから始めます。次に、上からコーディングを開始し、必要に応じてテストをパスするために徐々に下に向かって作業を進めます。

疑似コードに代わるものは、1000行の低レベルクラスを記述しないことです。代わりに、一番上から始めて、ドメインに対して理想的だが存在しないAPIを呼び出します。次に、APIをビルドします。

すべてのメソッドのリストをスキップして、継承階層を単に表示する場合でも、クラス図はほとんど努力する価値がないと思います。シーケンス図は良いですが、私（おそらく私だけ）に描いていると、ぎこちなく感じます。

データフローダイアグラムと構造図の方が便利だと思います（ただし、構造図は一般にBDUFに関連付けられているため、現時点では好まれません）。DFDは特に機能分解に役立ちます。DFDの各「バブル」は、必要な詳細レベルに到達するまで、独自のDFDに分解できます。

グラフィカルツールは疑似コーディングよりも優れていると思いますが、UMLは非常に複雑すぎて、これらの方法の欠点を組み合わせています:-)

もう少し明確に言うと、プログラミングは、特定の問題を分析し、より小さなコンポーネントとそれらの相互作用に分離する方法であると思います。これは「目的地ではなく旅」であり、問​​題に関する知識を常に向上させるため、コンポーネントのグラフが変化しています。レイヤーが表示されたり消えたり、関数やデータアイテムが上下に移動するなどです。

このプロセスを実行するための自然なツールは、スケッチボードです。できるだけ単純ですが、すばやく理解するのに十分なほど複雑です（同じ論理的な意味で同じ色、形、矢印）。私は銀の弾丸を見つけていません。おそらく私は自分で1日書きますが、今は気の利いた方法を使用しています。preziのズーム機能と組み合わせると、ほぼ完璧です。

なぜ疑似コーディングをしないのですか？疑似コーディングは、まだアイデアを形作る場合の実装、つまり「コンポーネントグラフのシリアル化された形式」への一歩前進です。良くない、頭を制限する。私の経験では、コーディングを始めるほど、捨てる必要のあるコードが少なくなることがわかりました...

しかし、おそらくこれは、スローされたコードをすべて記述したため、今は記述する必要がないためです。システムを設計するときに、それらから得た経験は私と一緒ですか？まあ、私はステートメントを変更する必要があります。

グラフが表示されず、同等の解決策が多数ある場合は、疑似コードに進むか、モックオブジェクトを使用してそのコードを記述します。Javaでは、ほとんど違いはありません。コードを見て、それらのコンポーネントの構造と使いやすさを感じてください。それは、グラフの修正と決定を行うのに役立ちます。しかし、これは、コードが悪いと感じてそのコードを破棄する準備ができている場合にのみ機能します。私はこれが疑似コードの利点だと思います：機能するときにそれを保持する誘惑は少ないですが、構造が間違っています（そしていつものように、十分な時間がありません）。:-)