UML có thực tế không? [đóng cửa]

Ở trường đại học, tôi đã có nhiều khóa học về thiết kế và định hướng UML , và tôi nhận ra rằng UML có thể được sử dụng để mang lại lợi ích cho một dự án phần mềm, đặc biệt là ánh xạ ca sử dụng , nhưng nó có thực sự thiết thực không? Tôi đã thực hiện một số điều khoản công việc co-op và có vẻ như UML không được sử dụng nhiều trong ngành. Có đáng để dành thời gian trong một dự án để tạo sơ đồ UML không? Ngoài ra, tôi thấy rằng sơ đồ lớp nói chung không hữu ích, bởi vì việc xem tệp tiêu đề cho một lớp sẽ nhanh hơn. Cụ thể những sơ đồ nào là hữu ích nhất?

Chỉnh sửa: Kinh nghiệm của tôi chỉ giới hạn ở các dự án nhỏ, dưới 10 nhà phát triển.

Chỉnh sửa: Nhiều câu trả lời hay, và mặc dù không dài dòng nhất, nhưng tôi tin rằng câu được chọn là cân bằng nhất.

Trong một hệ thống đủ phức tạp, có một số chỗ UMLđược coi là hữu ích.

Các sơ đồ hữu ích cho một hệ thống, thay đổi tùy theo khả năng ứng dụng.
Nhưng những cái được sử dụng rộng rãi nhất là:

• Sơ đồ lớp
• Sơ đồ trạng thái
• Sơ đồ hoạt động
• Sơ đồ trình tự

Có rất nhiều doanh nghiệp thề với họ và nhiều người hoàn toàn từ chối họ như một sự lãng phí thời gian và công sức.

Tốt nhất bạn không nên đi quá đà và nghĩ điều gì tốt nhất cho dự án mà bạn đang thực hiện và chọn những thứ có thể áp dụng và có ý nghĩa.

Sử dụng UML giống như nhìn vào đôi chân của bạn khi bạn bước đi. Đó là tạo ra một điều gì đó có ý thức và rõ ràng mà bạn thường có thể làm một cách vô thức. Người mới bắt đầu cần phải suy nghĩ cẩn thận về những gì họ đang làm, nhưng một lập trình viên chuyên nghiệp đã biết họ đang làm gì. Hầu hết thời gian, viết mã tự nó nhanh hơn và hiệu quả hơn viết về mã, bởi vì trực giác lập trình của họ được điều chỉnh theo nhiệm vụ.

Nó không chỉ là về những gì bạn đang làm. Điều gì về người thuê mới đến sau sáu tháng kể từ bây giờ và cần phải tăng tốc độ về mã? Còn năm năm nữa khi tất cả mọi người hiện đang làm việc trong dự án đều không còn nữa?

Sẽ vô cùng hữu ích khi có sẵn một số tài liệu cập nhật cơ bản cho bất kỳ ai tham gia dự án sau này. Tôi không ủng hộ các sơ đồ UML đầy đủ với tên phương thức và tham số (CÁCH quá khó để duy trì), nhưng tôi nghĩ rằng một sơ đồ cơ bản của các thành phần trong hệ thống với các mối quan hệ và hành vi cơ bản của chúng là vô giá. Trừ khi thiết kế của hệ thống thay đổi đáng kể, thông tin này sẽ không thay đổi nhiều ngay cả khi việc triển khai được điều chỉnh.

Tôi thấy rằng chìa khóa của tài liệu là kiểm duyệt. Không ai sẽ đọc 50 trang sơ đồ UML đầy đủ với tài liệu thiết kế mà không ngủ quên vài trang trong đó. Mặt khác, hầu hết mọi người đều muốn có được 5-10 trang sơ đồ lớp đơn giản với một số mô tả cơ bản về cách hệ thống được đặt lại với nhau.

Một trường hợp khác mà tôi thấy UML hữu ích là khi một nhà phát triển cấp cao chịu trách nhiệm thiết kế một thành phần nhưng sau đó giao thiết kế cho một nhà phát triển cấp dưới thực hiện.

Sử dụng UML giống như nhìn vào đôi chân của bạn khi bạn bước đi. Đó là tạo ra một điều gì đó có ý thức và rõ ràng mà bạn thường có thể làm một cách vô thức. Người mới bắt đầu cần phải suy nghĩ cẩn thận về những gì họ đang làm, nhưng một lập trình viên chuyên nghiệp đã biết họ đang làm gì. Hầu hết thời gian, viết mã tự nó nhanh hơn và hiệu quả hơn viết về mã, bởi vì trực giác lập trình của họ được điều chỉnh theo nhiệm vụ.

Ngoại lệ là tại sao bạn thấy mình trong rừng vào ban đêm mà không có ngọn đuốc và trời bắt đầu mưa - khi đó bạn cần quan sát chân để tránh bị ngã. Đôi khi nhiệm vụ bạn đảm nhận phức tạp hơn khả năng trực giác của bạn, và bạn cần giảm tốc độ và trình bày rõ ràng cấu trúc chương trình của mình. Sau đó, UML là một trong nhiều công cụ bạn có thể sử dụng. Những thứ khác bao gồm mã giả, sơ đồ kiến ​​trúc cấp cao và phép ẩn dụ kỳ lạ.

Luồng công việc và DFD chung có thể rất hữu ích cho các quy trình phức tạp. Tất cả các sơ đồ khác (ĐẶC BIỆT UML), theo kinh nghiệm của tôi, không có ngoại lệ là một sự lãng phí thời gian và công sức.

Tôi phải không đồng ý, UML được sử dụng khắp nơi - bất cứ nơi nào mà một dự án CNTT đang được thiết kế, UML thường sẽ ở đó.

Bây giờ nó có được sử dụng tốt hay không là một vấn đề khác.

Như Stu đã nói, tôi thấy cả Use Case (cùng với mô tả ca sử dụng) và sơ đồ hoạt động là hữu ích nhất theo quan điểm của nhà phát triển.

Biểu đồ lớp có thể rất hữu ích khi cố gắng hiển thị các mối quan hệ, cũng như các thuộc tính đối tượng, chẳng hạn như tính bền bỉ. Khi nói đến việc thêm các thuộc tính hoặc thuộc tính đơn lẻ, chúng thường quá mức cần thiết, đặc biệt là chúng thường nhanh chóng lỗi thời sau khi viết mã.

Một trong những vấn đề lớn nhất với UML là khối lượng công việc cần thiết để cập nhật nó khi mã được tạo ra, vì có rất ít công cụ có thể tái thiết kế UML từ mã và một số công cụ vẫn làm tốt.

Tôi sẽ đủ điều kiện cho câu trả lời của mình bằng cách đề cập rằng tôi không có kinh nghiệm trong các môi trường phát triển công ty lớn (giống như IBM).

Theo cách tôi xem UML và Quy trình hợp nhất hợp lý là nó nhiều NÓI về những gì bạn sẽ làm hơn là thực sự LÀM những gì bạn sẽ làm.

(Nói cách khác, phần lớn là lãng phí thời gian)

Vứt bỏ chỉ theo ý kiến ​​của tôi. UML là một công cụ tuyệt vời để truyền đạt ý tưởng, vấn đề duy nhất là khi bạn lưu trữ và duy trì nó vì về cơ bản bạn đang tạo ra hai bản sao của cùng một thông tin và đây là nơi mà nó thường xảy ra. Sau vòng triển khai đầu tiên, hầu hết UML sẽ được tạo từ mã nguồn, nếu không nó sẽ lỗi thời rất nhanh hoặc cần nhiều thời gian (với các lỗi thủ công) để cập nhật.

Tôi đã đồng dạy một khóa học về dự án phát triển cấp cao trong hai học kỳ cuối cùng của tôi ở trường. Dự án được dự định sử dụng trong môi trường sản xuất với các tổ chức phi lợi nhuận địa phương là khách hàng trả tiền. Chúng tôi phải chắc chắn rằng mã đã làm những gì chúng tôi mong đợi và rằng các sinh viên đang nắm bắt tất cả dữ liệu cần thiết để đáp ứng nhu cầu của khách hàng.

Thời gian trên lớp bị giới hạn, thời gian tôi ở ngoài lớp cũng vậy. Do đó, chúng tôi phải thực hiện đánh giá mã tại mỗi cuộc họp lớp, nhưng với 25 sinh viên đăng ký, thời gian xem xét cá nhân là rất ngắn. Công cụ mà chúng tôi thấy có giá trị nhất trong các buổi đánh giá này là ERD, sơ đồ lớp và sơ đồ tuần tự. Sơ đồ lớp và lớp học của ERD chỉ được thực hiện trong Visual Studio, vì vậy thời gian cần thiết để tạo chúng là rất nhỏ đối với sinh viên.

Các sơ đồ truyền đạt một lượng lớn thông tin rất nhanh chóng. Bằng cách có một cái nhìn tổng quan nhanh chóng về các thiết kế của sinh viên, chúng tôi có thể nhanh chóng tách các khu vực có vấn đề trong mã của họ và thực hiện đánh giá chi tiết hơn ngay tại chỗ.

Nếu không sử dụng sơ đồ, chúng tôi sẽ phải dành thời gian để xem từng tệp mã của sinh viên để tìm kiếm vấn đề.

Tôi đến chủ đề này hơi muộn và sẽ chỉ cố gắng làm rõ một vài điểm nhỏ. Hỏi xem UML có hữu ích không khi quá rộng. Hầu hết mọi người dường như trả lời câu hỏi từ UML điển hình / phổ biến dưới dạng phối cảnh công cụ vẽ / giao tiếp. Lưu ý: Martin Fowler và các tác giả sách UML khác cảm thấy UML chỉ được sử dụng tốt nhất cho giao tiếp. Tuy nhiên, có nhiều cách sử dụng khác cho UML. Trên hết, UML là một ngôn ngữ mô hình hóa có ký hiệu và sơ đồ được ánh xạ tới các khái niệm logic. Dưới đây là một số cách sử dụng UML:

• Giao tiếp
• Tài liệu Thiết kế / Giải pháp được Tiêu chuẩn hóa
• Định nghĩa DSL (Ngôn ngữ dành riêng cho miền)
• Định nghĩa mô hình (Cấu hình UML)
• Sử dụng mẫu / nội dung
• Tạo mã
• Chuyển đổi mô hình sang mô hình

Với danh sách sử dụng phía trên do Pascal đăng là không đủ vì nó chỉ nói đến việc tạo sơ đồ. Một dự án có thể được hưởng lợi từ UML nếu bất kỳ yếu tố nào ở trên là yếu tố thành công quan trọng hoặc là các lĩnh vực vấn đề cần một giải pháp tiêu chuẩn hóa.

Cuộc thảo luận nên mở rộng ra từ việc UML có thể được sử dụng như thế nào hoặc áp dụng cho các dự án nhỏ để thảo luận về thời điểm UML có ý nghĩa hoặc thực sự sẽ cải thiện sản phẩm / giải pháp vì đó là thời điểm UML nên được sử dụng. Có những tình huống mà UML cho một nhà phát triển cũng có thể cảm nhận được, chẳng hạn như Ứng dụng mẫu hoặc Tạo mã.

UML đã làm việc cho tôi trong nhiều năm. Khi tôi bắt đầu, tôi đã đọc UML Distilled của Fowler, nơi anh ấy nói "làm đủ mô hình / kiến ​​trúc / v.v.". Chỉ cần sử dụng những gì bạn cần !

Từ quan điểm của Kỹ sư QA, biểu đồ UML chỉ ra những sai sót tiềm ẩn trong logic và suy nghĩ. Giúp công việc của tôi dễ dàng hơn :)

Tôi nghĩ rằng UML là một ý tưởng hữu ích Tôi nghĩ rằng thông số kỹ thuật 2.0 đã làm cho những gì đã từng là một thông số kỹ thuật rõ ràng trở nên hơi cồng kềnh và cồng kềnh. Tôi đồng ý với ấn bản của sơ đồ thời gian, v.v. vì chúng đã lấp đầy khoảng trống ...

Học cách sử dụng UML hiệu quả cần một chút thực hành. Điểm quan trọng nhất là giao tiếp rõ ràng, làm mẫu khi cần thiết và làm mẫu như một đội. Bảng trắng là công cụ tốt nhất mà tôi tìm thấy. Tôi chưa thấy bất kỳ "phần mềm bảng trắng kỹ thuật số" nào quản lý để nắm bắt được tiện ích của bảng trắng thực tế.

Điều đó đang được nói rằng tôi thích các công cụ UML sau:

1. Violet - Nếu đơn giản hơn, nó sẽ là một tờ giấy

2. Altova UModel - Công cụ tốt cho lập mô hình Java và C #

3. MagicDraw - Công cụ thương mại yêu thích của tôi để tạo mô hình

4. Poseidon - Công cụ sang trọng với tiếng nổ tốt cho đồng tiền

5. StarUML - Công cụ mô hình mã nguồn mở tốt nhất

Biểu đồ UML hữu ích để nắm bắt và truyền đạt các yêu cầu và đảm bảo rằng hệ thống đáp ứng các yêu cầu đó. Chúng có thể được sử dụng lặp đi lặp lại và trong các giai đoạn lập kế hoạch, thiết kế, phát triển và thử nghiệm khác nhau.

Từ chủ đề: Sử dụng Mô hình trong Quy trình Phát triển tại http://msdn.microsoft.com/en-us/library/dd409423%28VS.100%29.aspx

Mô hình có thể giúp bạn hình dung thế giới mà hệ thống của bạn hoạt động, làm rõ nhu cầu của người dùng, xác định kiến ​​trúc của hệ thống, phân tích mã và đảm bảo rằng mã của bạn đáp ứng các yêu cầu.

Bạn cũng có thể muốn đọc phản hồi của tôi cho bài đăng sau:

Làm thế nào để học “thiết kế / kiến ​​trúc phần mềm tốt”? tại /programming/268231/how-to-learn-good-software-design-architecture/2293489#2293489

Mặc dù cuộc thảo luận này đã không hoạt động từ lâu, nhưng tôi có một vài điểm quan trọng - đối với tâm trí của tôi - cần bổ sung.

Mã lỗi là một chuyện. Còn lại để trôi về phía hạ lưu, những sai lầm trong thiết kế có thể trở nên rất cồng kềnh và xấu xí. Tuy nhiên, UML đang tự xác thực. Điều đó có nghĩa là tôi muốn cho phép bạn khám phá các mô hình của mình theo nhiều thứ nguyên, đóng theo toán học và kiểm tra lẫn nhau, nó tạo ra một thiết kế mạnh mẽ.

UML có một khía cạnh quan trọng khác: nó "nói chuyện" trực tiếp với khả năng mạnh nhất của chúng ta, đó là khả năng trực quan hóa. Ví dụ, nếu ITIL V3 (về cơ bản là đủ đơn giản) được giao tiếp dưới dạng biểu đồ UML, nó có thể đã được xuất bản trên vài chục bản gấp A3. Thay vào đó, nó xuất hiện trong một số chủ đề có tỷ lệ thực sự trong Kinh thánh, tạo ra toàn bộ ngành công nghiệp, chi phí ngoạn mục và cú sốc catatonic lan rộng.

Tôi thấy sơ đồ tuần tự và sơ đồ hoạt động được sử dụng khá thường xuyên. Tôi làm rất nhiều việc với các hệ thống nhúng và "thời gian thực" tương tác với các hệ thống khác và sơ đồ trình tự rất hữu ích trong việc hình dung tất cả các tương tác.

Tôi thích vẽ sơ đồ ca sử dụng, nhưng tôi chưa gặp quá nhiều người nghĩ rằng chúng có giá trị.

Tôi thường tự hỏi liệu Rational Rose có phải là một ví dụ điển hình về các loại ứng dụng bạn nhận được từ thiết kế dựa trên mô hình UML hay không. Nó cồng kềnh, lỗi, chậm chạp, xấu xí, ...

Tôi thấy UML không thực sự hữu ích cho các dự án rất nhỏ, nhưng thực sự phù hợp cho các dự án lớn hơn.

Về cơ bản, nó không thực sự quan trọng bạn sử dụng gì, bạn chỉ cần ghi nhớ hai điều:

• Bạn muốn một số loại quy hoạch kiến ​​trúc
• Bạn muốn chắc chắn rằng mọi người trong nhóm thực sự đang sử dụng cùng một công nghệ để lập kế hoạch dự án

Vì vậy, UML chỉ là: Một tiêu chuẩn về cách bạn lập kế hoạch cho các dự án của mình. Nếu bạn thuê người mới, có nhiều khả năng bạn biết bất kỳ tiêu chuẩn hiện có nào - có thể là UML, Flowchard, Nassi-Schneiderman, bất cứ điều gì - hơn là những thứ bạn đang sử dụng.

Với tôi, việc sử dụng UML cho một nhà phát triển và / hoặc một dự án phần mềm đơn giản có vẻ quá mức cần thiết, nhưng khi làm việc trong một nhóm lớn hơn, tôi chắc chắn muốn có một số tiêu chuẩn để lập kế hoạch phần mềm.

UML thực sự hữu ích! Những công dụng chính mà tôi đã thực hiện là:

• Suy nghĩ về cách thức hoạt động của một phần mềm. Nó giúp dễ dàng truyền đạt những gì bạn đang nghĩ.
• Ghi lại kiến ​​trúc của một hệ thống, các mẫu của nó và các mối quan hệ chính của các lớp của nó. Nó hữu ích khi ai đó vào nhóm của bạn, khi bạn rời đi và muốn đảm bảo rằng người kế nhiệm của bạn sẽ hiểu điều đó, và khi cuối cùng bạn quên mất lớp học nhỏ bé đó dùng để làm gì.
• Ghi lại bất kỳ mẫu kiến ​​trúc nào bạn sử dụng trên tất cả các hệ thống của mình, vì cùng lý do của dấu chấm ở trên

Tôi chỉ không đồng ý với Michael khi anh ấy nói rằng việc sử dụng UML cho một nhà phát triển và / hoặc một dự án phần mềm đơn giản có vẻ quá mức cần thiết đối với anh ấy. Tôi đã sử dụng nó trong các dự án cá nhân nhỏ của mình và việc chúng được ghi lại bằng UML đã giúp tôi tiết kiệm rất nhiều thời gian khi tôi quay lại với chúng bảy tháng sau và hoàn toàn quên mất cách tôi đã xây dựng và kết hợp tất cả các lớp đó.

Tôi tin rằng có thể có một cách để sử dụng các trường hợp sử dụng UML cá, diều và mực nước biển theo phong cách Cockburn như được Fowler mô tả trong cuốn sách "UML chưng cất". Ý tưởng của tôi là sử dụng các trường hợp sử dụng Cockburn như một sự hỗ trợ cho khả năng đọc mã.

Vì vậy, tôi đã thực hiện một thử nghiệm và có một bài đăng ở đây về nó với Thẻ "UML" hoặc "FOWLER". Đó là một ý tưởng đơn giản cho c #. Tìm cách nhúng các trường hợp sử dụng Cockburn vào không gian tên của các cấu trúc lập trình (chẳng hạn như không gian tên lớp và lớp bên trong hoặc bằng cách sử dụng không gian tên để liệt kê). Tôi tin rằng đây có thể là một kỹ thuật khả thi và đơn giản nhưng vẫn có những thắc mắc và cần người khác kiểm tra. Nó có thể tốt cho các chương trình đơn giản cần một loại Ngôn ngữ cụ thể miền giả có thể tồn tại ngay giữa mã c # mà không cần bất kỳ phần mở rộng ngôn ngữ nào.

Vui lòng kiểm tra bài viết nếu bạn quan tâm. Tới đây .

Một trong những vấn đề tôi gặp phải với UML là tính dễ hiểu của đặc tả. Khi tôi cố gắng thực sự hiểu ngữ nghĩa của một sơ đồ cụ thể, tôi nhanh chóng bị lạc trong mê cung của các mô hình meta và mô hình meta-meta. Một trong những điểm hấp dẫn của UML là nó ít mơ hồ hơn ngôn ngữ tự nhiên. Tuy nhiên, nếu hai hoặc nhiều hơn, các kỹ sư diễn giải một sơ đồ khác nhau, thì nó không đạt được mục tiêu.

Ngoài ra, tôi đã thử đặt các câu hỏi cụ thể về tài liệu siêu cấu trúc trên một số diễn đàn UML và cho các thành viên của chính OMG, nhưng không có kết quả. Tôi không nghĩ rằng cộng đồng UML đã đủ trưởng thành để tự hỗ trợ.

Xuất thân từ một sinh viên, tôi thấy rằng UML có rất ít công dụng. Tôi thấy thật mỉa mai khi PROGAMERS vẫn chưa phát triển một chương trình tự động tạo ra những thứ mà bạn đã nói là cần thiết. Sẽ cực kỳ đơn giản để thiết kế một tính năng vào Visual Studio có thể kéo các phần dữ liệu, tìm kiếm định nghĩa và câu trả lời về sản phẩm đủ để bất kỳ ai cũng có thể nhìn vào nó, dù lớn hay nhỏ và hiểu được chương trình. Điều này cũng sẽ giữ cho nó được cập nhật vì nó sẽ lấy thông tin trực tiếp từ mã để tạo ra thông tin.

UML được sử dụng ngay khi bạn biểu diễn một lớp với các trường và phương thức của nó mặc dù nó chỉ là một loại biểu đồ UML.

Vấn đề với UML là cuốn sách của những người sáng lập quá mơ hồ.

UML chỉ là một ngôn ngữ, nó không thực sự là một phương pháp.

Đối với tôi, tôi thực sự cảm thấy khó chịu khi thiếu lược đồ UML cho các Dự án nguồn mở. Lấy một cái gì đó như Wordpress, bạn chỉ có một lược đồ cơ sở dữ liệu, không có gì khác. Bạn phải đi lang thang xung quanh api codex để cố gắng có được bức tranh lớn.

UML có vị trí của nó. Nó ngày càng trở nên quan trọng khi quy mô của dự án ngày càng lớn. Nếu bạn có một dự án đang chạy dài, thì tốt nhất bạn nên ghi lại mọi thứ trong UML.

UML có vẻ tốt cho các dự án lớn với nhiều nhóm người. Tuy nhiên, tôi đã làm việc trong các nhóm nhỏ, nơi giao tiếp tốt hơn.

Mặc dù vậy, sử dụng sơ đồ UML-esque là tốt, đặc biệt là trong giai đoạn lập kế hoạch. Tôi có xu hướng suy nghĩ về mã, vì vậy tôi thấy việc viết các thông số kỹ thuật lớn rất khó. Tôi thích viết ra 'đầu vào và đầu ra' và để các nhà phát triển thiết kế bit ở giữa.

Tôi tin rằng UML hữu ích chỉ vì nó khiến mọi người suy nghĩ về mối quan hệ giữa các lớp của họ. Đó là một điểm khởi đầu tốt để bắt đầu nghĩ về những mối quan hệ như vậy, nhưng nó chắc chắn không phải là giải pháp cho tất cả mọi người.

Tôi tin rằng việc sử dụng UML là tùy thuộc vào tình huống mà nhóm phát triển đang làm việc.

Theo kinh nghiệm của tôi:

Khả năng tạo và giao tiếp các sơ đồ mã có ý nghĩa là một kỹ năng cần thiết cho bất kỳ kỹ sư phần mềm nào đang phát triển mã mới hoặc cố gắng hiểu mã hiện có.

Việc biết các chi tiết cụ thể của UML - khi nào sử dụng đường đứt nét hoặc điểm cuối hình tròn - không hoàn toàn cần thiết, nhưng vẫn tốt.

UML hữu ích theo hai cách:

• Về mặt kỹ thuật: nhiều người (người quản lý và một số nhà phân tích chức năng) nghĩ rằng UML là một tính năng xa xỉ vì Mã là tài liệu: bạn bắt đầu viết mã, sau khi gỡ lỗi và sửa chữa . Việc đồng bộ các biểu đồ UML với mã và các khóa xử lý buộc bạn phải hiểu rõ các yêu cầu của khách hàng;

• Về phía quản lý: biểu đồ UMl phản ánh yêu cầu của khách hàng là không chính xác: nếu bạn viết mã mà không có UML, có thể bạn có thể tìm thấy lỗi trong yêu cầu sau rất nhiều giờ làm việc. Sơ đồ UML cho phép bạn tìm ra những điểm có thể gây tranh cãi và giải quyết trước khi viết mã => giúp ích cho việc lập kế hoạch của bạn.

Nói chung, tất cả các dự án không có sơ đồ UML đều có phân tích hời hợt hoặc chúng có kích thước ngắn.

nếu bạn đang ở trong nhóm KỸ THUẬT HỆ THỐNG SYSTEMS , hãy xem cuộc thảo luận cũ của tôi .

Cuối cùng UML chỉ tồn tại vì RUP. Chúng ta có cần UML hoặc bất kỳ thứ gì liên quan đến nó để sử dụng Java / .Net không? Câu trả lời thiết thực là họ có tài liệu riêng của họ (javadoc, v.v.), điều này là đủ và cho phép chúng tôi hoàn thành công việc của mình!

UML không có than.

UML chắc chắn hữu ích vì junit rất cần thiết. Tất cả phụ thuộc vào cách bạn bán ý tưởng. Chương trình của bạn sẽ hoạt động mà không có UML cũng như nó sẽ hoạt động mà không có các bài kiểm tra đơn vị. Đã nói rằng, bạn nên tạo UML do nó được kết nối với mã của bạn, tức là khi bạn cập nhật sơ đồ UML, nó sẽ cập nhật mã của bạn hoặc khi bạn cập nhật mã, nó sẽ tự động tạo ra UML. Đừng làm chỉ vì lợi ích của việc đó.

UML chắc chắn có vị trí trong ngành. Hãy tưởng tượng bạn đang xây dựng phần mềm cho máy bay Boing hoặc một số hệ thống phức tạp khác. UML và RUP sẽ giúp ích rất nhiều ở đây.

UML chỉ là một trong những phương pháp giao tiếp giữa mọi người. Bảng trắng là tốt hơn.