ソフトウェアシステムをモデル化することと、すべてをコードで実行することの利点は何ですか？

私が知っているすべてのIT担当者ではないにしても、ほとんどの場合、コーディングの前にUMLまたは他のタイプのダイアグラムでソフトウェアをモデル化することが有益であると考えています。（私の質問は、特にUMLに関するものではなく、ソフトウェア設計のグラフィックまたはテキストによる説明です。）

私はそれについてはよくわかりません。主な理由は次のとおりです。コードは嘘をつかない。コンパイラーまたはインタープリターによってチェックされます。自動化されたテストがあり、静的コード分析に合格する必要があります。モジュールが別のモジュールと正しくインターフェイスしていない場合、エラーメッセージが表示されるため、通常はコードで明らかです。

このすべてを図や他のドキュメントで行うことはできません。はい、UMLをチェックするツールはありますが、これまで見てきたことはすべて非常に限られています。したがって、これらのドキュメントは不完全、一貫性のない、または単純な偽である傾向があります。

ダイアグラム自体が一貫していても、コードが実際にそれらを実装していることを確認することはできません。はい、コードジェネレーターはありますが、すべてのコードを生成することはありません。

モデリングの強迫観念は、コードが不可解に不可解な混乱であり、建築家、デザイナー、または全体像をつかむ他の有給の人々が対処する必要がないという前提から生じることに執着するように感じることがあります。そうでなければ、あまりにも高価になってしまいます。したがって、設計上のすべての決定は、コードから移動する必要があります。コード自体は、それを書くことができる（そしておそらく読むことができる）専門家（コードモンキー）に任せるべきですが、他に何も処理する必要はありません。これはおそらくアセンブラが唯一のオプションであったときに意味をなしましたが、最新の言語では非常に高いレベルの抽象化でコーディングできます。したがって、モデリングの必要性は実際にはありません。

ソフトウェアシステムをモデル化するための引数がありません。

ところで、図はソフトウェア設計の特定の側面を文書化して伝達するのに最適な方法であると考えていますが、それはソフトウェア設計をそれらに基づいて行うべきではないということです。

明確化：

この質問は不明確であるとして保留されています。したがって、いくつかの説明を追加しましょう。

私は、ソフトウェア設計に関する真実の主要な情報源としてソフトウェアをモデル化する（コードではない）ドキュメントを使用することが理にかなっているかどうかを尋ねています。コードの大部分がこれらのドキュメントから自動的に生成されることを念頭に置いていません。この場合、ドキュメント自体をモデルではなくソースコードと見なします。

この手順の欠点をいくつか挙げたので、（私の経験では）なぜ多くの人がこの手順をソフトウェア設計の好ましい方法と考えているのか疑問に思います。

ソフトウェアシステムとコード全体のモデリングの利点は次のとおりです。モデルをホワイトボードに収めることができます。

私は一枚の紙でコミュニケーションをとるという魔法を信じています。システムを新しいコーダーに教えるときにホワイトボードにコードを配置しようとした場合、ホワイトボードに収まる必要な抽象化レベルのコードはまったくありません。

あなたが言及しているモデリングへの執着を知っています。人々が物事をやっているのは、それが彼らが以前にやった理由だからです。私はそれを形式主義と呼ぶようになりました。伝統の背後に愚かさを隠すのは難しいので、私は非公式に働くことを好みます。

だからと言って、時々UMLスケッチを作成しません。しかし、コードを作成する前にUMLドキュメントを提出することを要求する男になることはありません。1人しか理解できないコードの存在に我慢できないので、5分かけてあなたが何をしているのかを説明するいくつかの方法を見つける必要があるかもしれません。

ファウラーは、UMLモードと呼ばれるUMLのさまざまな使用方法を特定しました。それらのすべての危険なことは、それらが有用な仕事をすることを隠すために使用できるということです。マウスを使用してコードを作成する場合は、多くの試みが行われています。誰もそれが本当に機能するのを見たことがありません。あなたがコミュニケーションのためにそれをしているなら、他の人があなたを理解していることを確認した方が良いでしょう。設計するためにそれをしているなら、作業中に問題を見つけて修正することができます。すべてが順調に進み、矢印の見栄えをよくするためにほとんどの時間が費やされたら、それをノックオフして仕事に戻ります。

最も重要なことは、1日以上有効であると予想される図を作成しないことです。どうにかできるなら、失敗しました。ソフトウェアはソフトであるためのものだからです。図を適切に取得するために数週間を費やさないでください。何が起こっているのか教えてください。必要な場合は、ナプキンを使用してください。

そうは言っても、UMLと設計パターンを知っているコーダーが好きです。コミュニケーションが簡単です。ダイアグラムの作成がフルタイムの仕事ではないことを知っている限り。

私は、ソフトウェアをモデル化する（コードではない）ドキュメントをソフトウェア設計に関する主な真実のソースとして使用することが理にかなっているかどうかを尋ねています

いいえ、これは理にかなっています。あなたのコードはあなたの主要な設計文書、すなわち「ソフトウェア設計に関する真実の主要な情報源」です。コンパイラーがその設計を採用し、そこからアプリケーションを作成するときに、アプリケーションの動作を正確に説明するのはコードのみです。

ダイアグラムを補助設計ドキュメントとして使用しますが、コードから自動生成されない場合は、実際のデザインとは異なるストーリーを伝えることに注意してください。UMLがボートを浮かせている場合は、それを使用します。そうでない場合は、別のものを使用します。

一部の人々は、コードを書き始める前に、自分の考えを図形式でスケッチするのが便利だと感じています。しかし、ボブおじさんがこの件について言ったことを覚えておいてください。

「あなたがそれらを検証するために、コードなしでそれらを作成するときに、はい、ダイアグラムは？それらが不適切。時には不適切であることができ、その後、それらを踏襲する考え。アイデアを探求するために図を描くと何も間違ってはあります。」

UMLを使用して設計を検討する場合は、コーディングを開始するときにそれらを捨ててください。テストを作成し、合格するコードを作成します。繰り返す。そうすれば、検証済みの設計になります。UMLは、デザインの同じレベルの検証を提供することはできません。

私が知っているすべてのIT担当者ではないにしても、ほとんどの場合、コーディングの前にUMLまたは他のタイプのダイアグラムでソフトウェアをモデル化することが有益であると考えています。

私はあなたが知っているすべての人がこれを信じていることに異論はありませんが、私はそれが必ずしも一般的なことだとは思いません。1970年、Winston Royceは、ソフトウェア開発には設計とコードアクティビティの間にある程度の反復があることを知っていました。1992年、Jack Reevesはコーディングが真の設計活動であることについて書きました（C2 Wikiでも議論されています）。

これは、人々がモデル駆動型の開発ツールを作成しようとしたという意味ではありません。UMLモデルからコードを生成しようとするツールがあります（クラス図だけでなく、さまざまなタイプの図をリンクし、それらからコードを生成します）。しかし、少なくとも私が見た限りでは、これらは広く使用されているツールではありません。

これはまた、要件からコードの記述にすぐに進むべきだという意味でもありません。早期に適切な設計を行うために重要な設計上の決定事項がいくつかあり、ある程度のモデリングは、全員がオプションとその影響を理解し、通信できるようにするのに役立ちます。一部の人々（私を含む）はこれを「ソフトウェアアーキテクチャ」と呼んでいます。

コードは嘘をつきません。コンパイラーまたはインタープリターによってチェックされます。自動化されたテストがあり、静的コード分析に合格する必要があります。モジュールが別のモジュールと正しくインターフェイスしていない場合、エラーメッセージが表示されるため、通常はコードで明らかです。

これは本当にアジャイルモデリングのいくつかの側面、特に実行可能な仕様と単一の情報源の中心です。私は必ずしもTDDに同意するわけではありませんが、コードと関連テスト（ユニットから受け入れテストまで、できれば自動テストとしてキャプチャされる）を単一の真実のソースにするというアイデアは良い考えです。

ダイアグラム自体が一貫していても、コードが実際にそれらを実装していることを確認することはできません。はい、コードジェネレーターはありますが、すべてのコードを生成することはありません。

一般的なルールとして、モデルからコードへの移行は間違った方法だと思います。代わりに、コードはモデルを生成する必要があります。つまり、ツールはコードを調べて、グラフィカルな表形式の表現を生成でき、エンジニアがそれらの周りにテキストを書くとさらに強化できるはずです。また、コードからのこのモデルの生成は、ビルドおよびリリースプロセスのシームレスな部分である必要があります。

さまざまな程度で、さまざまな言語でこれをサポートするツールがあります。言語とパラダイムの性質を考えると、他の人よりも簡単な人もいます。

この手順の欠点をいくつか挙げたので、（私の経験では）なぜ多くの人がこの手順をソフトウェア設計の好ましい方法と考えているのか疑問に思います。

これらの人々が必ずしもソフトウェア工学とソフトウェア設計を理解しているとは思わない。これらの人々は、他のエンジニアリング分野が何をしているかを見て、それをソフトウェアエンジニアがすべきだと思うものにマッピングしていると思います。しかし、彼らは1つの大きな違いを無視しています。他のエンジニアリング分野では、実際の製品を構築するのに非常に費用と時間がかかるため、最初にモデルとシミュレーションを作成します。ソフトウェアエンジニアリングでは、設計の一部を取り込んで、実世界の環境でテストできるものを、非常に短い時間と非常に少ないコストで作成できます。経済学は非常に異なっています。

ソフトウェアシステムをモデル化することと、すべてをコードで実行することの利点は何ですか？

あなたが非常に複雑なソフトウェアシステムを持っているとき、モデルを持つことは理解しやすい何かを持つことを意味します。これは異なるレベルの抽象化であり、システムのさまざまな側面を人々が理解するのに役立ちます。これは、さまざまな利害関係者がソフトウェアシステムを概念的にすばやく簡単に理解できるようにするために、非常に多くの異なるモデリング言語と各モデリング言語または表記法で許可される異なるタイプのモデルがある理由の1つです。

私は、ソフトウェア設計に関する真実の主要な情報源としてソフトウェアをモデル化する（コードではない）ドキュメントを使用することが理にかなっているかどうかを尋ねています。コードの大部分がこれらのドキュメントから自動的に生成されることを念頭に置いていません。この場合、ドキュメント自体をモデルではなくソースコードと見なします。

多くの非コードドキュメントは、設計図として役立ちます。つまり、設計の「真実」はこの方向に従う必要があります。これは、設計が満たさなければならない要素をモデル化する方法です。それらを要件ドキュメントと呼ぶこともできますが、それは私が提供できるすべての例では強すぎるかもしれません。PlantText.com経由でPlantUMLを使用してこれらを作成しました。

• ユースケース図は、目的の機能とユーザーまたは外部システムとの相互作用を示すことができます。

• アクティビティ図は、ソフトウェアがサポートする必要があるビジネスプロセスを示すことができます。

• 状態図は、Webサイトで意図した動的を示すことができます。

• Gang of Fourのデザインパターンは、静的および動的モデルとして表示されます。たとえば、Memento：
  
  

この手順の欠点をいくつか挙げたので、（私の経験では）なぜ多くの人がこの手順をソフトウェア設計の好ましい方法と考えているのか疑問に思います。

経験以外でUMLの使用に関する実際の情報に興味がある場合は、いくつかの研究が行われました（非ペイウォールの記事へのリンクを見つけようとしました）。

• ペトリ、マリアン（2013）。実際のUML。In：35th International Conference on Software Engineering（ICSE 2013）、2013年5月18-26日、カリフォルニア州サンフランシスコ、pp。722–731。
• N.マンガノ、TDラトーザ、M。ペトレ、A。ファンデルホーク（2015）。ソフトウェアデザイナーがホワイトボードでスケッチと対話する方法。In：IEEEトランザクションソフトウェアエンジニアリング、vol。41、いいえ。2、pp。135-156。
• アンドリュー・フォワードとティモシー・C・レスブリッジ。2008. モデル中心のソフトウェア開発とコード中心のソフトウェア開発の問題と機会：ソフトウェア専門家の調査 。ソフトウェアエンジニアリングのモデルに関する2008年国際ワークショップの議事録（MiSE '08）。ACM、ニューヨーク、ニューヨーク、米国、27〜32歳。

私たちの開発者は、世界を説明するために画像を使用するのが大好きなので、ここに車の生産の1つを示します。

• このクルマは、コードの場合と同様に、生産チェーンの結果です（もちろん、展開プロセスを追加します）。
• 車の設計文書は、ソフトウェアの設計文書と同じです。

私たちの世界では、設計ドキュメントを考案して作成する人がコードを作成する人と同じである場合よりもしばしば起こります。他のフィールドではそうではありません。しかし、だからといって、すべてを一緒に行うことで同じレベルの品質を実際に得ることができるというわけではありません。

コーディングせずに最初にこれらのドキュメントを作成することにより（使いやすさの概念実証などを除く）：

• 実行する前に必ず考えてください。実行する必要があることがわかったら、コーディングは簡単です。
• ソフトウェアの最も難しい部分に経験豊富な人々を集中させることができます。設計、アルゴリズム/数学は、非常に特定の目的（組み込み、リアルタイム、アセンブリ）を除いて任意です。
• 経験の浅い人はコーディングプロセスの大部分を委任できますが、経験のある人はスキルのレベルを必要とする最も重要な部分のみに集中できます。経験の浅い人はそれについて多くを学ぶでしょう。
• デザインドキュメントのイメージを通じて非IT担当者と話し合うことができますが、コードしか持っていない場合は、何かを忘れる危険を冒して、自分のしたことのイメージを抽出する必要があります（どこかで忘れられたリスナー...）。コミュニケーションの詳細については、CandiedOrangeの回答をご覧ください。
• ソフトウェアを進化させる必要がある場合、何が影響するかをよりよく予測できます。
• 設計により、ソフトウェアの一部を簡単に削減し、ソフトウェアの一部を同時に開発できます。
• コードを簡単にする前にテストをコーディングするTDDアプローチでは、それらのコーディング中にすべてのケースをカバーすることに頭痛を感じる必要がない場合、それらのいまいましい残忍な単体テストを書くのは簡単です。
• ...

注：これらの肯定は、コードが実際に設計を反映しており、両方とも最新の状態に維持されていることを前提としています...