Tại sao UML không được sử dụng trong hầu hết các phần mềm miễn phí (ví dụ: trên Linux)?

Tôi đang cố gắng hiểu tại sao UML không được sử dụng trong hầu hết các dự án phần mềm miễn phí . Ví dụ, hệ thống Debian / Linux của tôi có thể có hơn mười nghìn gói phần mềm miễn phí và tôi không thể đặt tên ngay cả một gói đã được phát triển bằng phương pháp và khuôn khổ UML rõ ràng . Ví dụ, Qt , GCC , Linux kernel , bash , GNU làm , Ocaml , Gnome , Unison , lighttpd , libonion , Docker là các dự án phần mềm miễn phí mà (AFAIK) không đề cập đến UML ở tất cả.

^{(Tôi đoán là UML rất phù hợp cho việc thầu phụ chính thức các nhiệm vụ phát triển và đó không phải là cách phần mềm miễn phí được phát triển)}

Lưu ý rằng trong khi tôi đã đọc một số tài liệu về UML, tôi không khẳng định rằng mình hiểu rõ về nó.

Trên thực tế, tôi không thể dễ dàng đặt tên cho một phần mềm miễn phí trong đó UML đã được sử dụng (ngoại trừ một số công cụ UML được triển khai dưới dạng phần mềm miễn phí). Có lẽ openstack là một ngoại lệ (một cái gì đó có đề cập đến UML).

^{(ngay cả các dự án phần mềm miễn phí cũ có thể đã áp dụng UML sau khi chúng được bắt đầu, nhưng chúng không làm như vậy)}

Một số đồng nghiệp làm việc trên Paccorus đã đề cập rằng hầu hết các dự án phần mềm miễn phí không có bất kỳ mô hình chính thức nào (và đủ sâu) rõ ràng. Ngoài ra, UML trông có liên quan nhiều đến Java hơn so với tuyên bố (tôi không hoàn toàn chắc chắn rằng nó sẽ có ý nghĩa đối với Ocaml hoặc Common Lisp hoặc Haskell hoặc Javascript, và có lẽ thậm chí không phải cho C ++ 11 ....). Có lẽ phát triển phần mềm nhanh không thân thiện với UML.

Xem thêm câu trả lời này cho một câu hỏi liên quan nào đó. Blog của M.Fowler là Thiết kế đã chết? là sâu sắc.

^{Tái bút Tôi không nghĩ rằng đó chủ yếu là vấn đề quan điểm; cần có một số lý do khách quan và một số đặc tính thiết yếu của phần mềm miễn phí, giải thích tại sao. Tôi có xu hướng đoán rằng UML chỉ hữu ích cho hợp đồng thầu phụ chính thức và chỉ hữu ích khi một phần của phần mềm được phát triển bị ẩn, như trong các dự án độc quyền. Nếu đó là sự thật, UML sẽ không tương thích với phát triển phần mềm miễn phí.}

^{NB: Bản thân tôi không phải là người hâm mộ UML. Tôi không định nghĩa UML chỉ là tài liệu giấy mà còn là định dạng dữ liệu [meta-] cho các công cụ phần mềm}

Có nhiều cách khác nhau để sử dụng UML. Martin Fowler gọi các chế độ UML này và xác định bốn chế độ : UML là Ghi chú , UML là Phác thảo , UML là Blueprint và UML là Ngôn ngữ lập trình .

UML như một ngôn ngữ lập trình không bao giờ thực sự cất cánh. Đã có một số công việc trong lĩnh vực này dưới các tên khác nhau, như Mô hình hướng dẫn mô hình hoặc Kỹ thuật phần mềm dựa trên mô hình. Theo cách tiếp cận này, bạn tạo các mô hình chi tiết cao của hệ thống phần mềm của bạn và tạo mã từ các mô hình đó. Có thể có một số trường hợp sử dụng trong đó phương pháp này hữu ích, nhưng không phải cho phần mềm nói chung và đặc biệt không nằm ngoài các công ty lớn có thể mua các công cụ hỗ trợ cho phương pháp này. Đây cũng là một quá trình tốn thời gian - Tôi có thể nhập mã cho một lớp nhanh hơn tôi có thể tạo tất cả các mô hình đồ họa cần thiết để thực hiện nó.

UML như là một Kế hoạch chi tiết thường là biểu hiện của một dự án "thiết kế lớn lên phía trước" . Nó không phải là, tất nhiên. Mô hình cũng có thể được mô tả đầy đủ cho một mức tăng cụ thể. Nhưng ý tưởng là thời gian dành cho việc tạo ra một thiết kế dưới dạng các mô hình UML sau đó được trao cho ai đó để chuyển đổi thành mã. Tất cả các chi tiết được đánh vần và việc chuyển đổi thành mã có xu hướng máy móc hơn.

UML như Phác thảo và UML như Ghi chú có bản chất tương tự nhau, nhưng khác nhau dựa trên thời điểm chúng được sử dụng. Sử dụng UML làm Phác thảo có nghĩa là bạn sẽ phác thảo các thiết kế bằng cách sử dụng các ký hiệu UML, nhưng các sơ đồ có thể chưa hoàn chỉnh, nhưng sẽ tập trung vào các khía cạnh cụ thể của thiết kế mà bạn cần giao tiếp với người khác. UML như Ghi chú là tương tự, nhưng các mô hình được tạo sau mã để hỗ trợ tìm hiểu cơ sở mã.

Khi bạn xem xét điều này, tôi nghĩ mọi thứ ở trên đều đúng với bất kỳ loại ký hiệu mô hình nào. Bạn có thể áp dụng nó cho các sơ đồ mối quan hệ thực thể, sơ đồ IDEF , ký hiệu mô hình hóa quy trình kinh doanh, v.v. Bất kể ký hiệu mô hình hóa, bạn có thể chọn khi bạn áp dụng nó (trước là một đặc điểm kỹ thuật, sau là một đại diện thay thế) và bao nhiêu chi tiết (chi tiết đầy đủ cho các khía cạnh chính).

Mặt khác của điều này là văn hóa nguồn mở.

Thông thường, các dự án nguồn mở bắt đầu để giải quyết vấn đề mà một cá nhân (hoặc, ngày nay, một công ty) đang gặp phải. Nếu nó được đưa ra bởi một cá nhân, số lượng nhà phát triển là 1. Trong trường hợp này, chi phí truyền thông cực kỳ thấp và không có nhu cầu giao tiếp về các yêu cầu và thiết kế. Trong một công ty, có khả năng là một nhóm nhỏ. Trong trường hợp này, bạn có thể sẽ cần truyền đạt các khả năng thiết kế và thảo luận về sự đánh đổi. Tuy nhiên, một khi bạn đã đưa ra quyết định thiết kế của mình, bạn cần duy trì các mô hình của mình khi cơ sở mã của bạn thay đổi theo thời gian hoặc vứt chúng đi. Trong thuật ngữ Agile Modelling , "tài liệu liên tục" và duy trì "một nguồn thông tin duy nhất" .

Tóm lại, có ý kiến ​​cho rằng mã là thiết kế và các mô hình chỉ là các khung nhìn thay thế của thiết kế. Jack Reeves đã viết ba bài tiểu luận về mã như thiết kế , và cũng có các cuộc thảo luận về wiki C2, thảo luận về các ý tưởng rằng mã nguồn là thiết kế , thiết kế là mã nguồn , và mã nguồn và mô hình hóa . Nếu bạn đăng ký vào niềm tin này (mà tôi làm), thì mã nguồn là thực tế và bất kỳ sơ đồ nào cũng nên tồn tại để hiểu mã và quan trọng hơn, lý do đằng sau lý do tại sao mã là gì.

Một dự án nguồn mở thành công, giống như những dự án mà bạn đề cập, có những người đóng góp trên khắp thế giới. Những người đóng góp này có xu hướng thành thạo về mặt kỹ thuật trong các công nghệ cung cấp năng lượng cho phần mềm và có khả năng cũng là người sử dụng phần mềm. Người đóng góp là những người có thể đọc mã nguồn dễ dàng như các mô hình và có thể sử dụng các công cụ (IDE và các công cụ kỹ thuật đảo ngược) để hiểu mã (bao gồm cả việc tạo các mô hình, nếu họ cảm thấy cần thiết). Họ cũng có thể tự tạo ra các bản phác thảo của dòng chảy.

Trong bốn chế độ mà Fowler mô tả, tôi không nghĩ rằng bạn sẽ tìm thấy một dự án nguồn mở, hoặc rất nhiều dự án ở bất cứ đâu, đang sử dụng các ngôn ngữ mô hình hóa như ngôn ngữ lập trình hoặc bản thiết kế. Điều này để lại các ghi chú và phác họa có thể sử dụng cho UML. Ghi chú sẽ được tạo bởi người đóng góp cho người đóng góp, vì vậy bạn có thể sẽ không tìm thấy chúng được tải lên ở bất cứ đâu. Phác thảo giảm giá trị khi mã trở nên hoàn thiện hơn và có khả năng sẽ không được duy trì vì điều đó sẽ chỉ nỗ lực từ phía những người đóng góp.

Nhiều dự án nguồn mở không có sẵn các mô hình vì nó không tăng thêm giá trị. Tuy nhiên, điều đó không có nghĩa là các mô hình không được tạo bởi ai đó sớm trong dự án hoặc các cá nhân chưa tạo ra các mô hình hệ thống của riêng họ. Nó chỉ hiệu quả hơn về thời gian để duy trì một nguồn thông tin thiết kế: mã nguồn.

Nếu bạn muốn tìm người trao đổi thông tin thiết kế, tôi khuyên bạn nên xem bất kỳ loại diễn đàn hoặc danh sách gửi thư nào được sử dụng bởi những người đóng góp. Thông thường, các diễn đàn và danh sách gửi thư này đóng vai trò là tài liệu thiết kế cho các dự án. Bạn có thể không tìm thấy UML chính thức, nhưng bạn có thể tìm thấy một số loại biểu diễn đồ họa của thông tin thiết kế và mô hình ở đó. Bạn cũng có thể vào phòng chat hoặc các kênh liên lạc khác cho dự án - nếu bạn thấy mọi người nói về quyết định thiết kế, họ có thể đang giao tiếp với các mô hình đồ họa. Nhưng họ có thể sẽ không trở thành một phần của kho lưu trữ vì chúng không có giá trị một khi họ đã phục vụ mục đích của họ trong giao tiếp.

Hãy sử dụng Linux làm ví dụ,

• Đây không phải là một dự án hướng đối tượng, một số phần, như VFS có thể được mô hình hóa trong UML, nhưng các phần khác không thể hoặc không hiệu quả, tức là về cơ bản chỉ là một bản dịch thẳng từ structsơ đồ lớp không có mối quan hệ.
• UML là tốt cho tài liệu, để có được một cái mới cho một dự án được tăng tốc. Đó không phải là thứ thực sự phục vụ cho Linux, mọi người dự kiến ​​sẽ tự học nó.
• Không chắc chắn nên sử dụng công cụ UML nào, mọi người cần phải đồng ý về một cái gì đó nếu nó sẽ được duy trì. Có một ứng dụng java miễn phí cho điều đó, nhưng tôi không nghĩ nhiều người muốn sử dụng nó.
• Trong GUI của thập niên 90 vẫn là một thách thức đối với Linux. Chỉ cần đi đào kho lưu trữ danh sách gửi thư, tôi cá rằng bạn sẽ không tìm thấy bất kỳ loại đồ họa nào ngoài logo cho chính Linux ở định dạng xpm sẽ được hiển thị trong thời gian khởi động. Văn bản thuần túy là định dạng ưa thích.
• Tôi không nghĩ rằng không ai thực sự quan tâm đến thiết kế. Mọi người quan tâm đến các tính năng và nếu chúng được chấp nhận thì mã sẽ được xem xét kỹ lưỡng. Các trường hợp sử dụng vẫn được mô tả tốt nhất bằng từ ngữ, giống như cách các tiêu chuẩn như POSIX và SUS được viết.
• Rất nhiều đối tượng trong lĩnh vực hệ điều hành được hiểu rõ và chuẩn hóa trong cộng đồng. Ví dụ, mọi người sẽ biết struct in_addrtrông như thế nào trong bộ nhớ, không có sơ đồ nào có thể làm cho nó rõ ràng hơn.
• UML không giúp ích nhiều trong thuật toán mô hình hóa, như bộ cấp phát bộ nhớ, bộ lập lịch, trình xử lý ngắt, v.v. Nguồn có lẽ dễ hiểu hơn.

Đó là những điều mà tôi có thể nghĩ đến trong các thiết lập dự án Linux. Đó là nhiều hơn về thực tiễn, tôi đoán. Thật kỳ lạ, tôi không nhớ Tanenbaum đã sử dụng bất kỳ UML nào trong sách giáo khoa hệ điều hành của mình để mô tả Minix.

Có lẽ đáng nói, tôi cũng không sử dụng UML tại nơi làm việc. Có lẽ 20% những người tôi làm việc cùng biết một số tập hợp con của UML.

UML là một đại diện, vì vậy nó là một dạng ngôn ngữ và vì lý do, hãy cho rằng mục đích của nó là truyền đạt một mô hình tinh thần từ người này sang người khác.

Điều tôi tìm kiếm trong một ngôn ngữ là hiệu quả của nó trong việc nắm bắt các thay đổi đối với mô hình tinh thần của một người. Giả sử sau khi viết mô tả về mô hình của một người, một thay đổi nhỏ cần được thực hiện. Làm thế nào lớn thay đổi phải được thực hiện cho đại diện? Trong một ngôn ngữ văn bản, một cách để đo lường đó là chạy một diffmã giữa mã trước và sau và đếm sự khác biệt. Trong một ngôn ngữ đồ họa, cần có một cách tương tự để đo lường sự khác biệt.

IMHO, tôi gọi một ngôn ngữ là "tên miền cụ thể" (DSL) đến mức độ tối thiểu hóa biện pháp trên, có lợi ích rõ ràng trong việc giảm chi phí bảo trì và lỗi. Làm thế nào để tạo DSL? Có một số cách. Một trong những cách đơn giản nhất là chỉ định nghĩa các cấu trúc và phương thức dữ liệu bằng ngôn ngữ lập trình hiện có. Điều này thêm danh từ và động từ vào ngôn ngữ cơ sở, giúp dễ dàng nói những gì người ta muốn. (Lưu ý: Tôi không tìm kiếm DSL không có đường cong học tập. Có thể người đọc DSL phải đầu tư chi phí một lần cho việc học nó.)

Điểm quan trọng là: Trong mọi trường hợp, DSL phải chứa các thuật ngữ giúp thể hiện mô hình của một người và thay đổi mô hình một cách thuận tiện. Vì không có giới hạn rõ ràng cho phạm vi của các miền có thể, nên không một DSL nào có thể phục vụ tất cả chúng.

Ấn tượng của tôi về UML là những gì nó đã cố gắng thực hiện.