UMLがほとんどのフリーソフトウェア（Linuxなど）で使用されないのはなぜですか？

UMLがほとんどのフリーソフトウェアプロジェクトで使用されていない理由を理解しようとしています。たとえば、私のDebian / Linuxシステムにはおそらく1万を超えるフリーソフトウェアパッケージがあり、明示的な UMLフレームワークと方法論を使用して開発されたものであっても名前を付けることはできません。例えば、Qtの、GCC、Linuxのカーネル、bashの、GNUのメイク、OCamlで、Gnomeの、ユニゾン、lighttpdの、libonion、ドッキングウィンドウは、すべてのUMLを言及していない（私の知る限り）のフリーソフトウェアプロジェクトです。

^{（私の推測では、UMLは開発タスクの正式な下請けに非常に適していると思いますが、それはフリーソフトウェアの開発方法ではありません）}

UMLに関する資料を読みましたが、それについて十分に理解しているとは主張していません。

実際、UMLが使用されているフリーソフトウェアに簡単に名前を付けることはできません（おそらく、フリーソフトウェアとして実装された一部のUMLツールを除く）。おそらくopenstackは例外です（UMLに言及しているものがあります）。

^{（古いフリーソフトウェアプロジェクトでさえ、開始後にUMLを採用したかもしれませんが、採用していませんでした）}

Papyrusに取り組んでいる一部の同僚は、ほとんどのフリーソフトウェアプロジェクトは、明確な（そして十分に深い）形式化されたモデルを最初から持っていないと述べました。また、UMLはJavaが主張するよりもはるかに関連しているように見えます（Ocaml、Common Lisp、Haskell、Javascript、さらにはC ++ 11でも意味がないかどうかはわかりません）。おそらく、アジャイルなソフトウェア開発はあまりUMLフレンドリーではありません。

何らかの形で関連する質問に対するこの回答も参照してください。M.ファウラーのブログはデザインが死んでいますか？洞察力があります。

^{PS。主に意見の問題だとは思わない。いくつかの客観的な理由と、フリーソフトウェアの本質的な特性があるはずです。UMLは、正式な下請けにのみ有用であり、独自のプロジェクトのように、開発されたソフトウェアの一部が隠されている場合にのみ有用であると推測する傾向があります。もしそうなら、UMLはフリーソフトウェア開発と互換性がありません。}

^{NB：私は自分でUMLファンではありません。私はUMLを紙の文書としてのみ定義するのではなく、ソフトウェアツールの [メタ]データ形式としても定義します}

UMLを使用するにはさまざまな方法があります。Martin FowlerはこれらのUMLモードを呼び出し、 4つを識別します。UMLはNotes、UMLはSketch、UMLはBlueprint、UMLはプログラミング言語です。

プログラミング言語としてのUMLが実際に普及したことはありません。この分野では、モデル駆動型アーキテクチャやモデルベースのソフトウェアエンジニアリングなど、さまざまな名前で作業が行われています。このアプローチでは、ソフトウェアシステムの非常に詳細なモデルを作成し、それらのモデルからコードを生成します。このアプローチが有用であるユースケースもありますが、一般的なソフトウェア、特にこのアプローチを推進するツールを購入できる大企業の外部には適していません。また、時間のかかるプロセスです。実装に必要なすべてのグラフィカルモデルを作成するよりも速くクラスのコードを入力できます。

ブループリントとしてのUMLは、多くの場合、「前もって設計された大きなデザイン」プロジェクトを示しています。もちろん、そうである必要はありません。モデルは、特定の増分についても完全に記述できます。しかし、アイデアは、コードを変換するために誰かに引き渡されるUMLモデルの形でデザインを作成するのに時間がかかるということです。詳細はすべて詳しく説明されており、コードへの変換はより機械的になりがちです。

SketchとしてのUMLとNotesとしてのUMLは本質的に似ていますが、使用されるタイミングによって異なります。UMLをスケッチとして使用するということは、UML表記を使用して設計をスケッチすることを意味しますが、図は完全ではない可能性がありますが、他の人と通信する必要がある設計の特定の側面に焦点を当てます。NotesとしてのUMLも似ていますが、モデルはコードベースの理解を支援するためにコードの後に​​作成されます。

あなたがこれを検討しているとき、私は上記のすべてがあらゆる種類のモデリング表記法に当てはまると思います。エンティティ関係図、IDEF図、ビジネスプロセスモデリング表記法などに適用できます。モデリング表記に関係なく、適用するタイミング（仕様として、前に代替表現として）と詳細度（主要な側面の詳細）を選択できます。

これの反対側は、オープンソース文化です。

多くの場合、オープンソースプロジェクトは、個人（または今日では企業）が経験している問題を解決するために開始されます。個人が起動する場合、開発者の数は1です。この場合、通信のオーバーヘッドは非常に低く、要件と設計について通信する必要はほとんどありません。会社では、小さなチームが存在する可能性があります。この場合、設計の可能性を伝え、トレードオフについて議論する必要があるでしょう。ただし、設計を決定したら、コードベースが時間とともに変化するときにモデルを維持するか、モデルを破棄する必要があります。でアジャイルモデリング用語は、「文書を連続的」と維持「情報の単一源」。

簡単に言うと、コードは設計であり、モデルは設計の代替ビューにすぎないという考えがあります。Jack Reevesは、デザインに関するコードについて3つのエッセイを執筆しました。また、C2 wikiでも議論があり、ソースコードはデザイン、デザインはソースコード、ソースコードとモデリングという考え方が議論されています。この信念に同意する場合（私はそうします）、ソースコードは現実であり、コードと、さらに重要なことには、コードがそれである理由の背後にある理論を理解するための図が存在する必要があります。

あなたが言及したような成功したオープンソースプロジェクトには、世界中に貢献者がいます。これらの貢献者は、ソフトウェアを動かす技術において技術的に有能である傾向があり、ソフトウェアのユーザーでもある可能性があります。貢献者は、ソースコードをモデルと同じくらい簡単に読むことができ、ツール（IDEおよびリバースエンジニアリングツール）を使用してコードを理解できる（必要に応じてモデルを生成することを含む）人です。また、フローのスケッチを自分で作成することもできます。

Fowlerが説明する4つのモードのうち、プログラミング言語または設計図としてモデリング言語を使用しているオープンソースプロジェクトや、非常に多くのプロジェクトを見つけることはないと思います。これにより、UMLの用途としてメモとスケッチが残ります。メモは寄稿者のために寄稿者によって作成されるため、おそらくどこにもアップロードされていないでしょう。スケッチは、コードがより完全になるにつれて価値が低下し、寄稿者の側で努力するだけで維持される可能性が低くなります。

多くのオープンソースプロジェクトは、価値を追加しないため、モデルを利用できません。ただし、プロジェクトの初期段階で誰かがモデルを作成したわけではなく、個人がシステムの独自のモデルを作成していないという意味でもありません。設計情報の1つのソースであるソースコードを維持するほうが、時間効率が向上します。

設計情報を交換している人を見つけたい場合は、寄稿者が使用しているあらゆる種類のフォーラムやメーリングリストを参照することをお勧めします。多くの場合、これらのフォーラムとメーリングリストは、プロジェクトの設計ドキュメントとして機能します。正式なUMLは見当たらないかもしれませんが、そこには何らかの設計情報とモデルのグラフィカルな表現が見つかるかもしれません。また、プロジェクトのチャットルームや他のコミュニケーションチャネルにアクセスすることもできます。デザインの決定について話している人がいる場合は、グラフィカルモデルと通信している可能性があります。しかし、コミュニケーションの目的を果たすと価値がなくなるため、リポジトリの一部にはなりません。

Linuxを例として使用してみましょう。

• オブジェクト指向のプロジェクトではありません。VFSのような一部のパーツはUMLでモデル化できますが、他のパーツは効果的ではないか、あまり効果的でstructはありません。
• UMLはドキュメント化に適しています。プロジェクトに新しいものを1つ追加すると、速度が上がります。これはLinuxが本当に提供するものではなく、人々は自分でそれを学ぶことが期待されています。
• 使用するUMLツールがわからないため、メンテナンスする場合は、何かに同意する必要があります。そのための無料のJavaアプリケーションがありましたが、多くの人がそれを使用したいとは思わないでしょう。
• 90年代のGUIは、Linuxでまだ課題でした。メーリングリストのアーカイブを調べてみてください。ブートアップ時に表示されるxpm形式のLinux自体のロゴ以外のグラフィックは見つかりません。プレーンテキストが優先形式です。
• 誰もデザインを気にかけていないと思います。人々は機能に関心があり、それらが受け入れられると、コードは精査されます。ユースケースは、POSIXやSUSなどの標準がどのように書かれているかのように、依然として言葉で最もよく説明されています。
• オペレーティングシステムのドメイン内の多くのオブジェクトは、コミュニティ内で十分に理解され、標準化されています。たとえばstruct in_addr、メモリ内のがどのように見えるかを知っている人はいれば、それを明確にする図はありません。
• UMLは、メモリアロケーター、スケジューラ、割り込みハンドラーなどのモデリングアルゴリズムにはあまり役立ちません。ソースはおそらく理解しやすいでしょう。

これらは、Linuxプロジェクトの設定で考えることができるものです。それは実用性に関するものだと思う。奇妙なことに、タネンバウムが彼のOSテキスト本でUMLを使用してMinixを説明したことは覚えていません。

言及する価値があると思いますが、私も仕事でUMLを使用していません。おそらく私と一緒に働いている人の20％がUMLのサブセットを知っています。

UMLは表現であるため、言語の形式であり、議論のために、その目的は、ある人から別の人にメンタルモデルを伝えることであると仮定しましょう。

私が言語で求めているのは、自分のメンタルモデルへの変更をキャプチャする効率です。モデルの説明を書いた後、少し変更する必要があるとします。表現にどの程度の変更を加える必要がありますか？テキスト言語で、それを測定する方法diffは、前後のコード間で実行し、違いを数えることです。グラフィカル言語では、違いを測定する同様の方法があるはずです。

私見、私は言語を「ドメイン固有」（DSL）と呼びます。それは上記の手段を最小化する程度で、メンテナンスコストとバグを減らすのに明らかな利点があります。DSLの作り方 いくつかの方法があります。最も簡単な方法の1つは、既存のプログラミング言語でデータ構造とメソッドを定義することです。これにより、基本言語に名詞と動詞が追加され、必要なものを簡単に言うことができます。（注：学習曲線を持たないDSLを探しているわけではありません。DSLの読者は、学習のための1回限りの費用を投資しなければならない可能性があります。）

重要な点は次のとおりです。すべての場合において、DSLには、自分のモデルおよびモデルの変更を簡単に表現する用語を含める必要があります。可能なドメインの範囲に明確な制限はないため、単一のDSLがそれらすべてを提供することはできません。

UMLに対する私の印象は、それが試みたものだということです。