私は先週、同僚と建築（建物の設計のような実際の建築）について話し合っていました。私たちの話の中で、建築の青写真は、建築家、土木技師、請負業者に、何かを構築するために必要なすべての詳細を提供することがわかりました。それは私たちの両方にソフトウェアエンジニアリングの状態について考えさせ、ソフトウェアの設計を記述するために普遍的に採用されたアプローチはないということでした。
UMLはありますが、図が複雑すぎない限り、十分な詳細を伝えるのは難しいことがよくあります。精巧なUML図を使用して設計された大規模なソフトウェアの良い例はありますか？
それでは、ソフトウェアの青写真の大規模なセットを持っていることはさらに有用ですか？結局のところ、ソフトウェアのリファクタリングと再構築は、超高層ビルを再構築するよりもはるかに安価です。アーキテクチャの青写真は、ソフトウェア設計の間違ったアナロジーですか？あなたが考えることができるより良いアナロジーはありますか？
ソフトウェア アーキテクチャを実際のアーキテクチャと比較することはできないと思います。家を建てるときは、すべてを前もって計画しておく必要があります。さらに重要なことは、ほとんどすべてを前もって計画できることです。
最近、ソフトウェア エンジニアリングは実際の建築よりもガーデニングに似ていると読みました。この比較はより現実に近いと思います。何がうまくいき、何がうまくいかないかを知ることはできません。理論的には良さそうに見えても実際的ではないことが判明したものを作り直す必要があり、庭/ソフトウェアがより完成度を高めている間、常に計画を改善できます。
要約すると、ソフトウェアの設計図は、家を建てるための設計図と同じレベルの詳細を持つべきではありません。
ソフトウェアの設計は青写真よりもMad-Libsに近いと思います
建築設計図は、実際の家をほぼ正確に表現したものです。それらは、通常、家がどのように見えるべきかのモデルに準拠する抽象化ではなく、家がどのようになるかを表現しています。
UML/フローチャート/Rational Rose/今月の方法論とは対照的です。これらはモデルです。彼らは実装の詳細を抽象化し、特定のモデル (たとえば、OO) がソフトウェアのあるべき姿であると想定しますが、実際には、モデルは適切な表現ではないため、ソフトウェアは常にそれらの抽象化を破っています。
ある意味では、これは説明力と計算可能性の問題に結びついています。家の設計図は、固定された表現と固定された入力による固定された表現です。一方、ソフトウェアの設計図は、場合によっては無制限の長さの可変入力を考慮しなければなりません。プラグインやその他の「コンピューティング」の連携を可能にするソフトウェアには、チューリング マシン オペレーターに相当するものが組み込まれているため、多くの予測不可能性が生じます。したがって、家に対するソフトウェアの入力空間は数学的に大きく、表現技術はそれに応じてより計算能力が高くなければなりません。そして、これがUMLらの場所です。落ちます - それらは実際のソフトウェアと同型ではありません。
ソフトウェアファクトリーでなされた議論の1つ：パターン、モデル、フレームワーク、およびツールを使用したアプリケーションのアセンブルは、UMLが適切ではないということです。制約を追加しても、それはまだ不明です。とりわけ、優れたコードを確実に生成できるという作者の意図を十分に表現していません。
UML は問題ありませんが、大まかに描かれたホワイトボードの図の写真は、実際には (時間/コストの意味で) 同じかそれ以上です。
つまり、攻撃を開始する前に砂の中に戦略を描くようなものであり、ほとんどの場合、その態度がうまく機能するようです.
さらに、半分の時間は、想像力に富み、実際の実装に投資しない人によって UML が描かれます。
DoD や FAA の兵器やセンサー システムなど、大規模で計算密度が高く、寿命が長く、セーフティ クリティカルなソフトウェア システムの場合、長期的な成功には設計図が不可欠です。(ふぅ、それは一口でした :)) これらの巨大な製品の一連の設計図がなければ、メンテナーや元の開発者でさえ、バグを見つけて修正したり、主要な機能を追加したりするときに、苦痛とフラストレーションを経験するでしょう。設計図がなければ、変更を組み込むことは、たとえ小さな変更であっても、リスクの高いゲームになり、失敗は下流で人命を失うことを意味する可能性があります。
そうは言っても、UML とその子孫である SysML は、(現在) 唯一のゲームです。モデリングと抽象化は、あいまいさと複雑さとの戦いにおいて重要なツールであり、将来さらに重要になるでしょう。成長したい人に受け入れられるのは早ければ早いほどよい。
聞いてくれてありがとう。
どんな比喩もここまでしか伸びないと思います。プログラミングのいくつかの側面を家を建てることと比較したり、さまざまな側面をガーデニング/チェスをしたり、頭の上に立って辞書を読んだりすることと比較することから価値が得られます...
建築プロジェクトを管理するために、しばらく前から一般的に受け入れられている慣行があるため、特定のプロジェクトに必要な詳細レベルを特定することは、建築においてより簡単だと思います。
おそらく50年後、誰もが方法論に落ち着いたら、私たちの業界でも同様のことが起こるでしょう.
通常、テキストと図の組み合わせは、アーキテクチャがどのように機能するかを説明する最良の方法です。Rational Rose でできることは、ここまでです。
ソフトウェアチームに「何かを構築するために必要なすべての詳細」を提供したい場合は、要件分析と明確な機能仕様の作成に力を入れてください。これには、顧客が望むすべての機能の説明が含まれます。これらの記述に UML 図が含まれている場合は、すべて問題ありません。多くの場合、UML は英語、フランス語、ドイツ語など、ソフトウェアを記述する言語よりも優れています。Joel on Software には、機能仕様の書き方に関する一連の特集記事があり、読む価値があります。ここから始めてください: http://www.joelonsoftware.com/articles/fog0000000036.html。
私の経験では、UML はガベージです。
TDD を使用することで、はるかに多くのことを達成でき、10000 倍の楽しみを得ることができます.. 飛び込んでテスト ケースを作成し、オブジェクトがどのように相互作用するかを確認することで。
UML の設計は最悪です。私はコーダーであり、データ入力タイプの人ではありません。
TDD の前は、ランダムな紙を使って基本的なエンティティと関係をスケッチし、すぐにコーディングに取り掛かりました。
これらのツールが一般的に使用されているとは思えず、人気も薄れています。
UML には限界があると言えます。はい、基本的な関係を表すことはできますが、相互作用と制約について考えると、まだあまり得られません (OCL を使用しても)。