ソフトウェアの設計をより効果的にキャプチャできないのはなぜですか？[閉まっている]

エンジニアとして、私たちは皆、アーティファクト（建物、プログラム、回路、分子など）を「設計」します。それは、何らかの結果（design-the-noun）を生成するアクティビティ（design-the-verb）です。

私たちは皆、design-the-nounがアーティファクト自体とは異なるエンティティであることに同意すると思います。

ソフトウェアビジネス（実際、製品成果物の強化が必要なビジネス）の主要な活動は、「デザイン（名詞）」を理解することです。しかし、私たちは、コミュニティとして、コードベースに関する事実を再発見するために人々が注いだ努力の量によって証明されるように、それを記録するのにほとんど完全に失敗しているように見えます。誰かにコードの設計を見せて、何が得られるかを見てもらいます。

ソフトウェアの設計には次のようなものがあると思います。

• ソフトウェアが何をすべきか、およびそれがどれだけうまく機能するかについての明示的な仕様
• コードの明示的なバージョン（この部分は簡単で、誰もが持っています）
• コードの各部分が仕様を達成するためにどのように機能するかについての説明（例えば、仕様フラグメントとコードフラグメント間の関係）
• 根拠のコードは、それがある方法です理由として（例えば、なぜ特定の選択ではなく別のものより）

デザインではないものは、コードに関する特定の観点です。たとえば、[特に選択しない] UMLダイアグラムは設計ではありません。むしろ、これらはコードから派生できるプロパティ、または間違いなくコードから派生したいプロパティです。ただし、一般的なルールとして、UMLからコードを派生させることはできません。

なぜ50年以上ソフトウェアを構築してきたのに、これを定期的に表現する方法がないのでしょうか？（明示的な例で私と矛盾することをお気軽に！）

たとえそうだとしても、コミュニティのほとんどは「コード」を取得することに集中しているようで、とにかくdesign-the-nounは失われます。（私見、デザインがエンジニアリングの目的になり、デザインからアーティファクトが抽出されるまで、これを回避するつもりはありません）。

デザインを記録するための手段としてあなたは何を見ましたか（私がそれを説明した意味で）？論文への明示的な言及は良いでしょう。特定の一般的な手段が成功しなかったのはなぜだと思いますか？これをどのように変更できますか？

[ 上記の箇条書きの視点を具体化する独自のアイデアを持っていますが、他の人の答えに興味があります...そして私のスキームを実装するのは難しいです[そしておそらくそれが本当の問題です：-]]

EDIT 2011/1/3：answer-threadsは、「文書化」（おそらくテキスト形式、特に非形式的）が適切である可能性があることを示唆しています。私はこれを信じていないことを明確にする必要があると思います。CASEツールは80年代からシーンに登場しましたが、初期のツールはほとんど、あなたが描いたものの図のピクセルをキャプチャしただけでした。ツールはほぼ間違いなく商業的に成功しましたが、実際にはあまり役に立ちませんでした。重要な洞察は、追加の「設計」アーティファクトが正式に解釈可能でない場合、深刻なツールヘルプを取得できないことでした。同じ洞察は、デザインキャプチャの長期的に有用な形式にも当てはまると思います。形式的な構造がなければ、実際に使用することはできません。テキスト文書はこのテストにほとんど失敗します。

まだこれが得意ではない理由はいくつかあると思います。

1. ソフトウェアは家のようなものであり、建設のプロセスとアイデアを使用していましたが、長い間人々はそうでした。「ソフトウェアアーキテクト」は、すべてのプログラマが望んでいたタイトルでした。過去10年間に、ソフトウェアアーキテクトはほぼ死亡しました。ウォーターフォールプロセスのアイデアでは、まずアーキテクトにソフトウェアの動作と外観を指示し、次にそれを構築する方法の図を作成させ、最後にコードモンキーがこれらの素晴らしいワークフロー/ UML図を仕様に実装するようにします。この考えは今広くwidelyされた。実際、業界全体が40年間間違った道を歩んできました。

2. 私たちが使用するツールは常に変化し、改善されています。プログラミングは論理的なパズルであり、そのパズルを抽象化して理解可能にするためのより良いアイデアとテクニックを考え出します。これをモデル化する方法は同じ速度で進化する必要がありますが、遅れています。プログラミングのパズルを抽象化する改善されたテクニックは、複雑さを増すこともできることを意味します。そして、そうします。プログラミングは常に、プログラマが処理できる複雑さの端にあります。

3. プログラムを記述する方法を作ることは、一種の抽象化です。ソフトウェアを抽象化する良い方法を思いつくことができれば、その抽象化を開発ツールに直接入れて、プログラミングに別の抽象化/単純化を追加することもできます。これは何度も起こりました。そのような抽象化の例は、関数、クラス、およびライブラリです。

4. したがって; ソフトウェアの成功した正確なモデルがある場合、そのモデルはソフトウェアと同等になります。これにより、全体の努力が無意味になり、それが上記のポイント1を裏付けます。ソフトウェアのモデリングは、以前考えられていたほど有用ではありません。代わりに、コードからソフトウェアに関するデータを抽出することをお勧めします。コードが実際にどのように見えるかからUMLモデルを作成することは、UMLモデルを作成してその理論モデルを実装しようとすることよりもはるかに賢明です。

ソフトウェアのトレーサビリティに関する資料を確認してください。順不同：

• CUBRANIC、D.、MURPHY、GC、SINGER、J。、およびBOOTH KELLOGG、S。Hipikat：ソフトウェア開発用のプロジェクトメモリ。ソフトウェアエンジニアリングに関するトランザクション31、6（2005）、446–65。
• TANG、A.、BABAR、MA、GORTON、I。、およびHAN、J。アーキテクチャ設計の理論的根拠の使用と文書化に関する調査。ソフトウェアアーキテクチャに関する第5回ワーキングIEEE / IFIP会議（2005年）のProc。
• RAMESH、B.、POWERS、T.、STABBS、C。、およびEDWARDS、M。要件のトレーサビリティの実装：ケーススタディ。要件工学に関する国際シンポジウムの講演（York、1995）。
• HORNER、J。、およびATWOOD、MEデザインの理論的根拠：理論的根拠と障壁。人間とコンピューターの相互作用に関する第4回北欧会議のプロセス：変化する役割（オスロ、ノルウェー、2006年）。
• CLELAND-HUANG、J.、SETTIMI、R.、ROMANOVA、E.、BERENBACH、B。、およびCLARK、S。自動トレーサビリティのベストプラクティス。コンピューター40、6（2007年6月）、27〜35。
• ASUNCION、H.、FRANÇOIS、F。、およびTAYLOR、RNエンドツーエンドの産業用ソフトウェアトレーサビリティツール。欧州ソフトウェア工学会議とソフトウェア工学の基礎に関するACM SIGSOFT国際シンポジウム（ESEC / FSE）の第6回合同会議の進行状況（Dubrovnik、2007）。

これは氷山の一角にすぎないことに注意してください。重要な論文をいくつか省いたに違いありません。

別の注意として、私自身のArcumでの仕事は、プログラマーがIDEに横断的なデザインのイディオムの使用を表現する手段でした。プログラマーは、表現されると、ソースコードを変換して代替実装を使用できます。

• マクニール・ショーン、ウィリアム・G・グリズウォルド、ソリン・ラーナー。リファクタリングを超えて：横断的な設計イディオムのモジュール式メンテナンスのためのフレームワーク。欧州ソフトウェア工学会議の第6回合同会議およびソフトウェア工学の基礎に関するACM SIGSOFTシンポジウムの議事録（ESEC-FSE '07; 2007年9月3〜7日）。175-184。

ちなみに、ArcumはDMSの作業にも関連しています。

UMLは、私のハンブビューでの建物の計画をプログラムに合わせたものです。計画だけではコース設計ではありません。そのための材料仕様（使用されるコードツール）、建物の一般的なビュー（GUIデザインを含むソフトウェア全体の概略図）、建物が周囲にどのように植えられているかが必要です。 （ソフトウェアが他のユーザーとどのように相互作用するか、OS内に植え付けられるかという明確なスキーム）、気候と土壌（ハードウェアとの相互作用）に耐える方法、...科学の多くのこと、すべての科学者は少し独自の定義を持っています。

また、UMLからコードを導出できないというあなたの観察にも同意しません。記載されている追加情報がある場合、できます。しかし、実際のコードはもはやデザインではなく、それがアーティファクトです。計画から本物の石とコンクリートを抽出することもできませんが、本物の石とコンクリートを正しい形と場所に配置する計画が必要です。

その観点から、私は次の記事を興味深いと感じました（グラフソフトウェアを探していたとき、別の文脈で会いましたが、それでも...）。デザインを説明するグラフのアプローチは私にとって理にかなっていますが、これもまた私の意見ではデザインの一部にすぎません。興味深いのは、次の論文で示されているように、このアプローチが設計を理解し、リファクタリングするためのフレームワークを提供することです（ソフトウェアをリファクタリングするのではなく）

• ヴェルメリンジャーとフィアデイロ

• Tsantalis et al

構造化設計（HIPOチャート）または統合プログラム設計、設計パターンなど、設計（の一部）を説明する他のアプローチが多数あります。

それでも、業界標準が設定されていない限り、これを「通常の」方法で表現することはできません。50年以上経っても。そして、正直に言って、もしあなたの会社がデザインを表現する良い方法を見つけたら、それを世界と共有しますか？

私自身の個人的な経験から、ソフトウェアの設計をうまく捉えていると主張します。プラットフォームにこれまでに実装したすべての機能の要件と設計ドキュメントのデータベースがあります。私の状況はおそらくユニークだと思います。ただし、次のことを考慮する必要があります。

私のチームの一人一人が工学の学位を持っています...ほとんどがEEまたはCEです。エンジニアリングでは、カリキュラムの一部として設計を教えます。

CSのバックグラウンドから来た、いわゆるソフトウェアエンジニアがたくさんいると思います。ソフトウェア設計は、ほとんどのCSプログラムの不可欠な部分ではありません。私はすべてのCS専攻がデザインが苦手だと言っているわけではありませんが、ほとんどの人がそれを教えた正式な教育を受けていないことを望みます。多くの人が、ソフトウェアを設計できるプログラムを作成できると思っていると思いますが、これは事実ではありません。多くのプログラマーがエンジニアリングのバックグラウンドを持っていないことを考えると、多くのソフトウェアプロジェクトがデザインのキャプチャに長けたチームを持っていないことは本当に驚くことではありません。

2つの問題があります。

1つ目は、コードとドキュメントの同期を維持するのが困難なことです。それらが分離している場合、それらは分岐し、ドキュメントは役に立たなくなります。プログラマーは、CASEツールなど、ツールを使用して同期を保つことを試みましたが、これらのツールはプログラマーとコードの間に入り込み、それは良いことよりも大きなダメージを与えました。ドメイン駆動設計（Evans、2004）の重要な洞察の1つは、優れた設計は非常に難しいということです。そのため、そこから何かを引き出すには、次のことが必要です。

• 優れたデザインが大きなメリットをもたらすプログラムの可能な限り小さな領域、いわゆるコアドメインを選択する
• すべてのチームメンバーが常に使用するユビキタス言語の形で優れたデザインを得るために本当に一生懸命働く
• 可能な限り、デザインをコードの一部にする

私たちが設計する方法に関する他の大きな問題は、私たちの設計方法が十分に数学的ではないということです。漏れやすい抽象化は、そこから堅実な結論を導き出すのに役立ちません。厳密に適用されたロジックと明確な真実の世界は、数学と呼ばれ、プログラマーは大抵は敬遠します。

正式な方法など、数少ない数学的ツールは非常に扱いにくいものです。

Map-reduceは、プログラミングにおける数学の良い例です。核となる考え方は次のとおりです。連想バイナリ操作がある場合、実行を非常に簡単に分散できます。二項演算は2つのパラメーターを持つ関数です。結合性は（a + b）+ c = a +（b + c）を意味します

a1 + a2 + ... + a99 + b1 + b2 + ... + b99 + c1 + c2 + ... + c99は

（a1 + a2 + ... + a99）+（b1 + b2 + ... + b99）+（c1 + c2 + ... + c99）As、Bs、およびCsを異なる場所に簡単に追加でき、結果が収集されますすぐに要約しました。

Map-reduceは、とんでもなくシンプルなアイデアです。一枚の紙で説明できます。読者が連想性の概念をしっかりと把握していると仮定できる場合、非常に小さな紙に収まる場合。ここで、連想という用語を使用したり間接的に参照したりすることなく、map-reduceを誰かに説明してみてください。出来ることならどうぞ。

数学的抽象化のないソフトウェア設計は、幾何学を習得することなくアーキテクチャを実行しようとするようなものです。

たぶん、Haskellはこれをやがて修正できるでしょう。カテゴリー理論の概念を使用してプログラムを記述することは、私にとって有望に見えます。カテゴリー理論は非常に抽象的であるため、数学者でさえほとんど使用しませんでしたが、明らかにカテゴリーは認識を超えて抽象的であり、ソフトウェアの構造を説明するのに十分抽象的であるようです。わかります。ゆっくり。