Các sơ đồ UML quan trọng như thế nào đối với một dự án thành công? [đóng cửa]

Tôi đang ở giữa một dự án và tôi được yêu cầu viết sơ đồ UML (trường hợp sử dụng, sơ đồ lớp, v.v.). Dự án không phức tạp lắm.

Tôi đã tự hỏi nếu điều này là một sự lãng phí thời gian của tôi? Tôi có nên làm những việc thú vị khác như viết mã không? Và khi nào không ổn để xây dựng một cái gì đó mà không trải qua tất cả các giai đoạn khái niệm? Có phải tất cả về sự phức tạp? Và nếu vậy, làm thế nào để đo lường nó?

Tôi là một fan hâm mộ lớn của UML một thời gian trước đây. Tôi thậm chí còn được chứng nhận OMG. Tôi đã sử dụng nó rộng rãi trong các dự án doanh nghiệp lớn mà tôi đã tham gia.

Hôm nay, tôi đã dừng UML gần như hoàn toàn. Đôi khi, tôi sử dụng sơ đồ trình tự mà tôi thấy rất hữu ích để mô tả các tương tác giữa các hệ thống, nhưng không có sơ đồ nào khác.

Bây giờ tôi thích làm việc với các câu chuyện của người dùng, được hỗ trợ bởi cả hai (chỉ) tài liệu cần thiết được viết bởi chủ sở hữu sản phẩm (hoặc nhà phân tích) VÀ sự cống hiến của họ (của họ) cho nhóm phát triển để cung cấp thêm chi tiết khi cần.

UML là một công cụ bạn có thể sử dụng, nhưng chắc chắn nó không phải là yếu tố quyết định cho sự thành công của các dự án của bạn. Sau nhiều năm, bây giờ tôi nghĩ yếu tố quan trọng là đội ngũ phát triển, bất kể nó sử dụng công cụ nào.

Kế hoạch là rất quan trọng, nhưng như chiến lược gia nổi tiếng Carl von Clausewitz cảnh báo

Không có kế hoạch chiến dịch nào tồn tại trong lần tiếp xúc đầu tiên với kẻ thù

Vì vậy, nó không phải là một sự lãng phí lớn thời gian để lập kế hoạch làm thế nào để tấn công các vấn đề ban đầu. Nhưng có thể lãng phí thời gian để ghi lại mã của bạn cho các lập trình viên trong tương lai. Để sử dụng một phép ẩn dụ quân sự, bạn cần một kế hoạch chiến đấu, nhưng bạn sẽ không đưa kế hoạch đó cho các nhà sử học để sử dụng như một báo cáo hành động.

Cụ thể hơn, bạn có thể sử dụng các sơ đồ này để truyền đạt ý định của bạn trong nhóm của bạn và suy nghĩ về kế hoạch tấn công của bạn trước và trong dự án. Nhưng tỷ lệ cược là những gì bạn đưa ra sẽ cần phải được điều chỉnh khi bạn viết mã và tìm hiểu thêm về vấn đề. Hầu như luôn luôn kế hoạch / thiết kế ban đầu của bạn cần được thay đổi bởi vì bạn không thể biết mọi thứ ở phía trước.

Tôi nghĩ rằng các sơ đồ UML chỉ có thể hữu ích nếu chúng thể hiện một cái gì đó ở mức độ trừu tượng cao hơn mã của bạn .

Viết UML chỉ vì mục đích viết UML trở nên quan liêu không cần thiết và làm cho dự án và mã không thích ứng với các thay đổi mà không có lợi ích gì.

Ví dụ, sơ đồ lớp UML hiển thị tất cả các lớp trên một gói, với tất cả các thuộc tính và phương thức của chúng - một cái gì đó có thể dễ dàng tự động tạo ra - không cung cấp giá trị nào cả: nó ở cùng mức độ trừu tượng hơn mã của bạn . Thêm vào đó, mã chắc chắn sẽ là một nguồn tốt hơn cho thông tin đó bởi vì nó sẽ luôn được cập nhật và có lẽ nó sẽ được ghi lại và tổ chức theo cách dễ dàng hơn để biết phương thức / thuộc tính / điều nào quan trọng hơn.

Mặt khác, nếu bạn có các khái niệm về mức độ trừu tượng cao hơn những gì có thể được thể hiện trên mã, thì việc ghi lại những điều đó trên sơ đồ có thể là một ý tưởng tốt.

Ví dụ, một sơ đồ hiển thị các mô-đun trừu tượng cấp cao hơn trên một hệ thống phức tạp, với các phụ thuộc của chúng và có thể mô tả một chút về trách nhiệm của chúng và gói / không gian tên mà chúng ánh xạ tới trong mã nguồn có thể thực sự hữu ích cho một thành viên nhóm mới cần được giới thiệu cho dự án, hoặc cũng có thể được sử dụng để tìm ra nơi một lớp / chức năng mới sẽ được ném.

Một ví dụ khác về sơ đồ hữu ích có thể là sơ đồ trình tự hiển thị các bước cấp cao được thực hiện trong giao thức truyền thông. Có thể mỗi bước của những điều đó có một chút kỳ quặc và phức tạp, nhưng có lẽ nó đủ để mô tả chúng trong chính mã. Sơ đồ cấp cao hơn có thể giúp lập trình viên hiểu "bức tranh lớn" của mọi thứ một cách dễ dàng mà không cần phải lo lắng về sự phức tạp của mỗi tương tác.

Dù sao, đó chỉ là một số ví dụ; có rất nhiều trường hợp trong đó một sơ đồ đơn giản có thể giúp ích rất nhiều. Chỉ cần nhớ rằng bạn chỉ nên thực hiện chúng khi bạn không thể thể hiện điều gì đó trong chính mã. Nếu bạn thấy mình sử dụng các sơ đồ UML để giải thích chính mã nguồn, hãy tạo mã soruce để tự viết tài liệu hơn.

Cuối cùng, một số quy tắc chung áp dụng cho mã cũng có thể áp dụng cho sơ đồ: tránh lặp lại chính mình, giữ cho nó đơn giản, không sợ thay đổi mọi thứ (chỉ vì một cái gì đó được ghi lại trên sơ đồ UML không có nghĩa là không thể được thay đổi) và luôn nghĩ về ai sẽ đọc / duy trì các sơ đồ đó trong tương lai (có thể là bản thân tương lai của bạn) khi viết chúng :)

UML có giá trị nếu các thành viên trong nhóm cùng nhau hiểu nó và coi đó là một cách hữu ích để tóm tắt và truyền đạt các quyết định thiết kế. Bạn không cần phải biết tất cả, chỉ cần tập hợp con mà nhóm tìm thấy hữu ích.

Ngoài ra, bạn không cần phải vẽ sơ đồ hoàn hảo, bóng bẩy. Một sơ đồ trình tự được phác thảo sơ bộ trên bảng trắng hoặc sơ đồ lớp trong đó các lớp là ghi chú sau nó được dán vào bảng trắng đó có thể là đủ, tùy thuộc vào ngữ cảnh.

Tôi đã từng làm việc trong một buổi biểu diễn mà tôi cần để quản lý một nhóm các nhà phát triển hợp đồng ở nước ngoài.

Một số thứ họ đang sản xuất khá kinh khủng (một triệu chứng phổ biến của các lập trình viên hợp đồng từ xa - họ không thực sự quan tâm nhiều đến mã của bạn, họ chỉ muốn hoàn thành nhanh).

Để quản lý dự án, tôi thấy mình tạo ra các sơ đồ UML và giao nó cho họ viết mã. Nó đã rất thành công - tôi không mất nhiều thời gian để viết một chương trình bằng UML, nhanh hơn nhiều so với Java và đó là điều mà các nhà thầu có thể làm theo và được đo lường.

Một cảnh báo - đôi khi họ đã muốn trở nên sáng tạo và đi chệch khỏi mô hình của tôi, tuy nhiên trong những trường hợp đó họ thực sự đúng và trên tất cả UML đã cải thiện chất lượng của sản phẩm cuối cùng

Nếu ai đó yêu cầu bạn chuẩn bị sơ đồ UML và ai đó đang trả lương cho bạn, thì đó không thực sự là một sự lãng phí thời gian của bạn. Nó có thể hoặc không lãng phí thời gian của ai đó.

Nếu ai đó đang có kế hoạch hiểu dự án của bạn bằng cách đọc sơ đồ UML của bạn, thì có lẽ đó không phải là một sự lãng phí thời gian của họ.

Tôi thấy nó hữu ích ở giai đoạn thiết kế ban đầu để lấy ý tưởng trên giấy hoặc trên bảng trắng. Tôi chủ yếu sử dụng sơ đồ lớp UML, không tuân thủ nghiêm ngặt các tiêu chuẩn. Rất hữu ích để xem lại thiết kế ban đầu UML của bạn khi bạn thực hiện một phần và cả khi kết thúc dự án. Nó đã giúp tôi xem xét một codebase ở mức độ trừu tượng cao hơn mà bạn từng có thể chỉ bằng cách đọc qua mã, và thậm chí còn giúp phát hiện ra các lỗi tiềm ẩn.

Có một điểm hay được thực hiện ở đây bởi ragu.pattabi phân biệt giữa hai loại UML ...

Tôi nghĩ rằng hương vị nhanh nhẹn của UML (ví dụ: phác thảo bảng trắng nhanh) thành công hơn hương vị thác nước của UML (ví dụ: sơ đồ phức tạp với tất cả các chi tiết chính xác cho tài liệu, tạo mã, v.v. để làm cho các nhà quản lý hiểu biết tài liệu hài lòng).

Khi UML được xem là một kỹ năng 'phải có' (10 năm trước trở lên), tôi có lẽ đã chống lại nó do quan điểm của nhiều người hâm mộ tại thời điểm đó. Nhưng bây giờ nó không còn được ưa chuộng nữa, tôi thấy mình đã thấy nó là gì - một công cụ hữu ích có công nhưng không phải là viên đạn bạc trong phát triển phần mềm.

Tôi sử dụng UML (hoặc sth tương tự UML :)) khi tôi nói chuyện với bạn bè về những điều chúng tôi sắp làm. Để thảo luận về ý tưởng. Không chuẩn bị dự án UML sẽ tự động tạo mã cho tôi. Tôi không thể tưởng tượng việc tạo các lớp của mình trong UML sau đó tạo mã và không chỉnh sửa nó sau này. Điều này không bao giờ xảy ra. Vì vậy, bạn sẽ phải mang các thay đổi từ mã sang UML. Và khi tôi sử dụng UML, tôi vẽ trên bảng trắng hoặc giấy. Không bao giờ trong công cụ như Enterprise Architect.

Lý do duy nhất để ghi lại toàn bộ mã của tôi trong UML sẽ là một hợp đồng mà khách hàng yêu cầu. Ví dụ: khi anh ta muốn có một tùy chọn để thay đổi cửa hàng phần mềm sau khi một phần của phần mềm kết thúc.

Tài liệu công việc dự án là một giao hàng cơ bản của một dự án chuyên nghiệp. Bao nhiêu thì đủ? Vâng, tất nhiên nó phụ thuộc vào nhiều yếu tố. Tuy nhiên, theo tôi, các trường hợp sử dụng, sơ đồ lớp, sơ đồ quy trình, v.v ... hoàn toàn không lãng phí thời gian. Họ có giá trị trong các giai đoạn dự án khác nhau. Vấn đề duy nhất với tài liệu thường là tài nguyên.

Một số lập trình viên coi tài liệu là một sự lãng phí thời gian. Nhưng điều này là không đúng sự thật. Nếu bạn xem tài liệu như một màn hình hiển thị các quy tắc thiết kế và hệ thống của bạn một cách thanh lịch và rõ ràng, bạn có thể đến để đánh giá cao nó hơn. Ngoài ra, người ta cần đặt bản thân của mình vào vị trí của những người cần duy trì hệ thống. Bị ném 500 tệp mã và được yêu cầu khắc phục các sự cố với chúng là loại xấu nhưng không phổ biến.

Tôi đề nghị bạn phân bổ thời gian trong dự án của bạn và tạo ra các sơ đồ theo chu kỳ. Đầu tiên sẽ bao gồm các khía cạnh cấp cao của dự án của bạn và các cấp tiếp theo có thể tập trung hơn vào các chi tiết.

Các trường hợp sử dụng đặc biệt không thể được suy luận dễ dàng từ mã (không giống như nhiều khía cạnh khác của hệ thống). Hãy chắc chắn rằng bạn làm những điều đó.

UML là một công cụ, không có gì hơn, và nó có hữu ích hay thậm chí rất quan trọng chỉ phụ thuộc vào quy trình phát triển và thiết kế của bạn. Có nhiều cách đến Rome và một số trong số đó liên quan đến UML, trong khi những cách khác thì không.

Nếu quy trình công việc của bạn dựa trên UML để ghi lại hoặc lên kế hoạch cho kiến ​​trúc của bạn, thì việc bỏ nó sẽ là điều ngớ ngẩn. Nếu UML là cách tốt nhất có thể để truyền đạt cấu trúc dự án đến các thành viên khác trong nhóm (theo nghĩa rộng hơn), thì bằng mọi cách, hãy sử dụng nó. Nhưng nếu dự án hoạt động tốt mà không có UML, thì việc tạo các sơ đồ UML chỉ vì lợi ích của nó là vô nghĩa.

Tôi có một vài suy nghĩ về điều này. Ngôn ngữ có thể được sử dụng và lạm dụng, bắt buộc và đánh lạc hướng, kích hoạt và ru ngủ. UML chỉ là một ngôn ngữ khác phù hợp với một nhóm vấn đề cụ thể và cũng như bất kỳ ngôn ngữ nào khác, sẽ cần thời gian và nỗ lực để học nói trôi chảy và hiểu chính xác.

Quyết định về những gì cần giao tiếp là vô cùng quan trọng hơn ngôn ngữ mà nó được truyền đạt. UML sẽ không làm cho các thiết kế xấu của bạn trở nên dễ hiểu. Cũng giống như bất kỳ ngôn ngữ nào khác, rất dễ bị lạc trong chi tiết hoặc để lại quá nhiều cho trí tưởng tượng.

UML có một tên xấu vì có nhiều IDE khủng khiếp, cho phép tạo mẫu khứ hồi, thao tác đồ thị nhấp chuột và khó thay đổi bất cứ điều gì. UML 2.0 có thể đủ phức tạp để đáp ứng các học giả nhất định, nhưng mô hình meta của nó dường như không thu hút được nhiều ứng dụng thực tế.

Thỉnh thoảng, tôi vẫn sử dụng UML. Để đánh giá một thiết kế cấp cao (một thiết kế tốt có sự phức tạp ở rìa và sự đơn giản ở trung tâm). Để truyền đạt ý tưởng cho đồng nghiệp và nhận phản hồi. Để tìm các mối quan hệ ẩn, bình thường hóa, vv Nhưng nó luôn luôn là một sự phản ánh của một cái gì đó đã có trong đầu tôi. Nói chung, tôi vẽ UML bằng bút và giấy, tốt nhất là cách xa mọi máy tính. Nếu cần thiết, khi một thiết kế kết tinh, tôi tạo một biểu diễn trực quan trong một chương trình vẽ.

UML hoàn toàn tuyệt vời để có được chế độ xem đồ họa của kiến ​​trúc của bạn bằng sơ đồ lớp. Tương tác sử dụng sơ đồ trình tự là ma thuật đối với tôi. Do đó, vấn đề không phải là UML mà là MDD đối với tôi.

Ý tôi là nếu UML là người xem mã thì nó thực sự hữu ích cho mục đích tài liệu nhưng chắc chắn không phải để tạo mã. Dự án nên là mã trung tâm và chắc chắn không phải là mô hình hướng trung tâm. UML nên được sử dụng ở giai đoạn triển khai bằng cách sử dụng mã trực tiếp và đồng bộ hóa mô hình. Tôi có nghĩa là không chỉ ở mức yêu cầu mà cần đầu tư quá nhiều cho lợi nhuận nhỏ về năng suất và chất lượng.

Tôi thấy họ được đánh giá cao. Tôi coi chúng là những bức tranh duy nhất không vẽ một ngàn chữ.

UML chỉ có giá trị nếu những người thiết kế hệ thống không thể tự viết mã. tức là, UML là một "ngôn ngữ" truyền đạt các khái niệm kiến ​​trúc cho người khác, bây giờ nếu bạn là người đang thiết kế mã và thực hiện nó, thì tại sao bạn cần phải chỉ cho mình biết bạn sẽ làm gì ?! Thay vào đó và đi thẳng cho mã hóa thay thế. Bạn vẫn sẽ phải ghi lại những gì bạn đã làm sau đó, nhưng hiệu quả tổng thể nhanh hơn.

Nhưng, nếu bạn là một kiến ​​trúc sư hệ thống muốn nói với nhóm các nhà phát triển thuê ngoài của bạn những gì bạn muốn, thì bạn phải nói với họ bằng cách nào đó, và đó là nơi UML xuất hiện. Tuy nhiên, tôi nghĩ rằng có rất nhiều phương tiện biểu diễn thay thế nhiệm vụ này ngày nay và thật lòng mà nói, sự phức tạp của sơ đồ UML có nghĩa là mọi người phải hiểu cách đọc nó, điều này có phần tự đánh bại nếu họ không làm thế.

Tôi chưa bao giờ là một fan hâm mộ của UML, nhưng tôi đã đánh giá cao một sơ đồ trình tự tốt để mô tả các tương tác giữa các hệ thống hoặc tác vụ.

Tuy nhiên, sơ đồ lớp đã lỗi thời trước khi nó được sinh ra. Một thiết kế thô không yêu cầu UML và một tài liệu kỹ lưỡng được trích xuất tự động (trực tiếp) tốt hơn từ cơ sở mã. Javadoc và Doxygen đã hoàn toàn lỗi thời sự cần thiết của sơ đồ lớp thủ công.

Điều về tài liệu là có hai cấp độ:

• quyết định cấp cao (kiến trúc) nên được tài liệu thủ công
• sự kiện cấp thấp (mối quan hệ thực thể) nên được trích xuất tự động

Tôi thường lặp lại giữa các sơ đồ mã và UML. Tôi thấy rằng các sơ đồ giúp hiển thị bức tranh lớn và một con đường vững chắc phía trước và chúng có thể được thay đổi khá nhanh khi các vấn đề được phát hiện. Ngoài ra, khi tôi có sơ đồ, mã hóa có xu hướng trở nên tầm thường.

Ngược lại, khi tôi vẽ mã bằng hình ảnh, nó phơi bày các vấn đề phụ thuộc và làm cho các cơ hội cải tiến thiết kế rõ ràng, điều mà có lẽ sẽ không được chú ý nếu chúng ta chỉ có mã để làm việc. Đặc biệt, nếu đó là một nỗi đau để vẽ, thì nó cũng sẽ là một nỗi đau để mã hóa và một cơn ác mộng để duy trì.

Tôi đã thấy rằng việc lặp lại là bắt buộc, bởi vì chỉ vẽ các bức tranh luôn bỏ lỡ các khía cạnh quan trọng, trong khi chỉ mã hóa dẫn đến các thiết kế có vấn đề.

Tuy nhiên, giống như một poster khác đã nói, tất cả sôi sục trước mọi người. Nếu họ có kỹ năng "sử dụng" các sơ đồ UML thì UML là vô giá. Nếu chúng không có thì sơ đồ không có giá trị.

Vì vậy, câu trả lời cho câu hỏi của bạn thực sự là "nó phụ thuộc". Trong trường hợp này, nó phụ thuộc vào con người, sự phức tạp của dự án và tầm quan trọng của việc hệ thống hoạt động đúng.

Theo kinh nghiệm của tôi, UML rất quan trọng đối với việc giao tiếp giữa các nhà phát triển về các mẫu mã và kiến ​​trúc nói chung của ứng dụng.

Tôi thích sơ đồ, nhưng nếu tôi được yêu cầu tạo một (đặc biệt là UML!), Tôi sẽ hỏi hai câu hỏi:

1. Nó dành cho ai?
2. Họ có cần nó bây giờ không?

Sơ đồ đi ra khỏi ngày ngay lập tức. Vì vậy, trừ khi bạn đang sử dụng nó để liên lạc với ai đó, nó sẽ bị thối rữa. Và nếu người mà bạn giao tiếp sẽ làm tốt hơn với một mô tả văn bản, hoặc một cuộc gọi điện thoại, hoặc một bản tóm tắt không chính thức trên bảng trắng - thay vào đó, hãy đề xuất điều đó.

Một trong những điểm thu hút chính đối với tôi về các sơ đồ UML như tôi đã thấy chúng được sử dụng cho đến nay là chúng hầu như chỉ có xu hướng đóng vai trò là "những bức tranh đẹp" trên tường của ai đó hoặc như một trang gấp trong một ràng buộc ở đâu đó và hiếm khi được dùng làm đường cơ sở cho một mã sản xuất.

Trong loại kịch bản này - các sơ đồ UML (hoặc bất kỳ hương vị nào của ngôn ngữ mô hình hóa mà bạn sử dụng) hiếm khi hữu ích về lâu dài, vì chúng có xu hướng bị mất liên quan khi thời gian tiếp tục và dự án phát triển. Những bản vẽ ban đầu này hầu như vô dụng và không chính xác trong thời gian vài năm và có chúng xung quanh là chủ yếu có hại.

Điều đó nói rằng, sử dụng các công cụ mô hình hóa (không nhất thiết là UML) không hoàn toàn là thực hành vô dụng, nếu các mô hình cung cấp đầu vào trực tiếp thực tế và có liên quan đến mã chạy thực tế. Nếu mô tả mô hình là một tạo phẩm hữu ích của mã, thì nó nên được coi là mã:

Hoặc bằng cách sử dụng nó làm nguồn siêu dữ liệu trực tiếp để đưa ra quyết định động dựa trên các khái niệm được mô hình hóa hoặc sử dụng tạo mã để tạo các tạo phẩm mã tĩnh được sử dụng trong mã làm việc thực tế.

Không biết câu hỏi là về giá trị của UML hay về giá trị của việc thiết kế kiến ​​trúc của các chương trình.

Về UML. Bạn thường chỉ cần: trường hợp sử dụng, sơ đồ lớp và sơ đồ trình tự. Đơn giản và dễ dàng, mặc dù bạn có thể làm điều đó chắc chắn với các loại sơ đồ của riêng bạn. Về vấn đề này, UML là một tiêu chuẩn mọi người sẽ hiểu.

Về thiết kế chương trình.

1. Mỗi chương trình đều có một thiết kế, ngay cả khi bạn không lập kế hoạch. Khi mã được viết, chỉ cần thiết kế ngược lại. Nếu bạn không lên kế hoạch, đặt cược nó sẽ là một thiết kế tồi.

2. Thiết kế sẽ giúp bạn tiết kiệm thời gian, bằng cách sử dụng các mẫu đã biết cho các sự cố lặp lại.

3. Nếu bạn làm việc trong một nhóm, thiết kế là cần thiết để thảo luận về các giải pháp, để truyền tải ý tưởng, và rất thực tế nhưng cần thiết, để phân phối công việc.