ソフトウェアの設計をより効果的にキャプチャできないのはなぜですか？[閉まっている]
閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 エンジニアとして、私たちは皆、アーティファクト（建物、プログラム、回路、分子など）を「設計」します。それは、何らかの結果（design-the-noun）を生成するアクティビティ（design-the-verb）です。 私たちは皆、design-the-nounがアーティファクト自体とは異なるエンティティであることに同意すると思います。 ソフトウェアビジネス（実際、製品成果物の強化が必要なビジネス）の主要な活動は、「デザイン（名詞）」を理解することです。しかし、私たちは、コミュニティとして、コードベースに関する事実を再発見するために人々が注いだ努力の量によって証明されるように、それを記録するのにほとんど完全に失敗しているように見えます。誰かにコードの設計を見せて、何が得られるかを見てもらいます。 ソフトウェアの設計には次のようなものがあると思います。 ソフトウェアが何をすべきか、およびそれがどれだけうまく機能するかについての明示的な仕様 コードの明示的なバージョン（この部分は簡単で、誰もが持っています） コードの各部分が仕様を達成するためにどのように機能するかについての説明（例えば、仕様フラグメントとコードフラグメント間の関係） 根拠のコードは、それがある方法です理由として（例えば、なぜ特定の選択ではなく別のものより） デザインではないものは、コードに関する特定の観点です。たとえば、[特に選択しない] UMLダイアグラムは設計ではありません。むしろ、これらはコードから派生できるプロパティ、または間違いなくコードから派生したいプロパティです。ただし、一般的なルールとして、UMLからコードを派生させることはできません。 なぜ50年以上ソフトウェアを構築してきたのに、これを定期的に表現する方法がないのでしょうか？（明示的な例で私と矛盾することをお気軽に！） たとえそうだとしても、コミュニティのほとんどは「コード」を取得することに集中しているようで、とにかくdesign-the-nounは失われます。（私見、デザインがエンジニアリングの目的になり、デザインからアーティファクトが抽出されるまで、これを回避するつもりはありません）。 デザインを記録するための手段としてあなたは何を見ましたか（私がそれを説明した意味で）？論文への明示的な言及は良いでしょう。特定の一般的な手段が成功しなかったのはなぜだと思いますか？これをどのように変更できますか？ [ 上記の箇条書きの視点を具体化する独自のアイデアを持っていますが、他の人の答えに興味があります...そして私のスキームを実装するのは難しいです[そしておそらくそれが本当の問題です：-]] EDIT 2011/1/3：answer-threadsは、「文書化」（おそらくテキスト形式、特に非形式的）が適切である可能性があることを示唆しています。私はこれを信じていないことを明確にする必要があると思います。CASEツールは80年代からシーンに登場しましたが、初期のツールはほとんど、あなたが描いたものの図のピクセルをキャプチャしただけでした。ツールはほぼ間違いなく商業的に成功しましたが、実際にはあまり役に立ちませんでした。重要な洞察は、追加の「設計」アーティファクトが正式に解釈可能でない場合、深刻なツールヘルプを取得できないことでした。同じ洞察は、デザインキャプチャの長期的に有用な形式にも当てはまると思います。形式的な構造がなければ、実際に使用することはできません。テキスト文書はこのテストにほとんど失敗します。