UMLがほとんどのフリーソフトウェア（Linuxなど）で使用されないのはなぜですか？
私は理解しようとしています理由 [〜＃〜] uml [〜＃〜] はほとんどの フリーソフトウェア プロジェクトで使用されていません。たとえば、私のDebian/Linuxシステムにはおそらく1万個を超えるフリーソフトウェアパッケージがあり、explicitUMLフレームワークと方法論を使用して開発されたものも挙げられません。たとえば、 Qt 、 [〜＃〜] gcc [〜＃〜] 、 Linuxカーネル 、 bash 、 GNU make 、 Ocaml 、 Gnome 、 nison 、 lighttpd 、 libonion 、 docker は、（AFAIK）がUMLについてまったく言及していないフリーソフトウェアプロジェクトです。
（私の推測では、UMLは開発タスクの正式な外注に非常に適していると思います。つまり、フリーソフトウェアの開発方法はではありません）
UMLに関する資料を読んだことはありますが、UMLについて十分に理解しているとは言えません。
実際、UMLが使用されているフリーソフトウェアを簡単に挙げることはできません（おそらく、フリーソフトウェアとして実装されている一部のUMLツールを除く）。おそらく openstack は例外です（UMLについて言及されているもの）。
（古いフリーソフトウェアプロジェクトでさえ、開始後にUMLを採用した可能性がありますが、採用しませんでした）
Papyrusに取り組んでいる一部の同僚は、ほとんどのフリーソフトウェアプロジェクトには、最初は明確に（そして十分に深い）形式化されたモデルがなかったと述べました。また、UMLはJavaに関連しているように思われます（Ocaml、Common LISP、Haskell、Javascript、およびC++ 11でもおそらく意味があるかどうかは完全にはわかりません） ....）。たぶん アジャイルソフトウェア開発 は、UMLフレンドリーではありません。
参照 this どういうわけか関連する質問への回答。 M.Fowlerのブログ Is Design Dead？ は洞察に富んでいます。
PS。主に意見の問題ではないと思います。理由を説明するいくつかの客観的な理由と、フリーソフトウェアのいくつかの本質的な特性があるはずです。私は、UMLが正式な下請け契約にのみ役立ち、独自のプロジェクトのように、開発されたソフトウェアの一部が隠されている場合にのみ役立つと推測する傾向があります。それが本当なら、UMLはフリーソフトウェア開発とincompatibleになります。
注意：私自身はUMLのファンではありません。私はUMLを紙のドキュメントとしてだけでなく、ソフトウェアツールの[メタ]データ形式としても定義しています
UMLの使用方法はいくつかあります。 Martin FowlerはこれらのUMLモードを呼び出します で、次の4つを識別します： MLをノートとして 、 MLをスケッチとして 、 MLをブループリントとして 、および プログラミング言語としてのUML 。
プログラミング言語としてのUMLが実際に普及したことはありません。 Model Driven Architecture やModel Based Software Engineeringなど、さまざまな名前でこの領域でいくつかの作業が行われています。このアプローチでは、ソフトウェアシステムの非常に詳細なモデルを作成し、それらのモデルからコードを生成します。このアプローチが役立ついくつかのユースケースがあるかもしれませんが、一般的なソフトウェアではなく、特にこのアプローチを可能にするツールを購入できる大企業の外ではありません。また、時間のかかるプロセスです。クラスのコードを、それを実装するために必要なすべてのグラフィカルモデルを作成するよりも速く入力できます。
ブループリントとしてのUMLは、多くの場合 "big design up front" プロジェクトを示しています。もちろんそうである必要はありません。モデルは、特定の増分についても完全に説明できます。しかし、アイデアは、コードを変換するために誰かに渡されるUMLモデルの形式でデザインを作成することに費やされるということです。詳細はすべて詳細に記述されており、コードへの変換はより機械的になる傾向があります。
スケッチとしてのUMLとノートとしてのUMLは本質的に似ていますが、いつ使用されるかによって異なります。 UMLをスケッチとして使用するということは、UML表記法を使用して設計をスケッチすることを意味しますが、図は完全ではない可能性がありますが、他のユーザーと通信する必要がある設計の特定の側面に焦点を当てます。 NotesとしてのUMLも同様ですが、モデルはコードベースの理解を助けるためにコードの後に作成されます。
これを検討しているとき、私は上記のすべてがあらゆる種類のモデリング表記に当てはまると思います。エンティティリレーションシップダイアグラム、 [〜＃〜] idef [〜＃〜] ダイアグラム、ビジネスプロセスモデリング表記などに適用できます。モデリングの表記に関係なく、いつ適用するか（仕様の前、代替表現として）、詳細（重要な側面の詳細）を選択できます。
これの反対側はオープンソース文化です。
多くの場合、オープンソースプロジェクトは、個人（または今日、企業）が直面している問題を解決するために始まります。個人が起動する場合、開発者は1人です。この場合、通信のオーバーヘッドは非常に低く、要件と設計について通信する必要はほとんどありません。会社では、小さなチームがいる可能性があります。この場合、設計の可能性を伝え、トレードオフについて話し合う必要があるでしょう。ただし、設計を決定したら、コードベースが時間とともに変化するときにモデルを維持するか、モデルを破棄する必要があります。 アジャイルモデリング の条件では、 "ドキュメントの継続的" と "単一の情報ソース" を維持します。
簡単に言うと、コードは設計であり、モデルは設計の代替ビューに過ぎないという考えがあります。 Jack Reevesはコードとしての3つのエッセイをデザインとして書いた であり、C2 wikiでもディスカッションが行われ、 ソースコードはデザイン 、 theデザインはソースコードです 、そして ソースコードとモデリング です。あなたがこの信念（私がそうする）に同意する場合、ソースコードは現実であり、コードを理解するために図が存在する必要があります。さらに重要なのは、コードがなぜそれが何であるかを裏付ける根拠です。
成功したオープンソースプロジェクトは、あなたが言及しているプロジェクトのように、世界中に貢献者がいます。これらの寄稿者は、ソフトウェアを強化する技術に技術的に優れている傾向があり、ソフトウェアのユーザーでもある可能性があります。寄稿者とは、モデルと同じくらい簡単にソースコードを読み取ることができ、ツール（IDEおよびリバースエンジニアリングツール）を使用してコード（必要に応じてモデルの生成を含む）を理解できる人です。また、自分でフローのスケッチを作成することもできます。
Fowlerが説明する4つのモードの中で、モデリング言語をプログラミング言語または青写真として使用しているオープンソースプロジェクト、または非常に多くのプロジェクトはどこにも見当たらないと思います。これにより、UMLの可能な使用法としてメモとスケッチが残ります。ノートはコントリビューターのためにコントリビューターによって作成されるため、どこにもアップロードされていない可能性があります。スケッチは、コードがより完全になると価値が低下し、寄稿者の側で努力するだけなので維持されない可能性があります。
多くのオープンソースプロジェクトは、付加価値がないため、利用可能なモデルを備えていません。ただし、それはモデルがプロジェクトの早い段階で誰かによって作成されなかったこと、または個人がシステムの独自のモデルを作成していないことを意味するものではありません。設計情報の1つのソース、つまりソースコードを維持する方が時間効率が良いだけです。
設計情報を交換する人を見つけたい場合は、寄稿者が使用しているあらゆる種類のフォーラムやメーリングリストを確認することをお勧めします。多くの場合、これらのフォーラムとメーリングリストは、プロジェクトの設計ドキュメントとして機能します。正式なUMLは見当たらないかもしれませんが、設計情報やモデルのある種のグラフィック表現が見つかるかもしれません。チャットルームやプロジェクトの他の通信チャネルにポップすることもできます。設計の決定について話している人を見かけたら、彼らはグラフィカルモデルと通信している可能性があります。ただし、コミュニケーションで目的を果たした後は価値がなくなるため、リポジトリの一部にならない可能性があります。
UMLは表現であるため、言語の1つの形式であり、議論のために、その目的がメンタルモデルを人から人へ伝達することであると仮定しましょう。
私が言語で求めているのは、メンタルモデルの変更をキャプチャする効率です。モデルの説明を書き込んだ後、小さな変更を加える必要があるとします。表現にどれほど大きな変更を加える必要がありますか？テキスト言語では、それを測定する方法は、コードの前後でdiffを実行し、違いをカウントすることです。グラフィカル言語では、違いを測定する同様の方法があるはずです。
私見、私は言語を「ドメイン固有」（DSL）と呼びます。これは、上記の対策を最小限に抑えます。これは、メンテナンスコストとバグの削減に明らかな利点があります。 DSLの作り方いくつかの方法があります。最も単純な方法の1つは、既存のプログラミング言語でデータ構造とメソッドを定義することです。これにより、名詞と動詞がベース言語に追加され、必要なことを簡単に言うことができます。 （注：学習曲線がないDSLを探しているわけではありません。DSLの読者は、それを学習するための1回限りのコストを投資しなければならない可能性があります。）
重要な点は次のとおりです。すべての場合において、DSLには、自分のモデルを表現し、モデルへの変更を便利にする用語を含める必要があります。可能なドメインの範囲に明らかな制限がないため、単一のDSLですべてのドメインを処理することはできません。
UMLの私の印象はそれがそれを試みたものです。