Vì vậy, khi tôi ở trường đại học, tôi đã được giáo dục về lợi ích của UML và tương lai của nó trong việc phát triển mã.

Nhưng từ kinh nghiệm trong ngành của tôi, tôi đã thấy rằng trong khi chúng tôi sử dụng sơ đồ, từ sơ đồ ER, sơ đồ lớp, sơ đồ trạng thái, đến sơ đồ dòng công việc, tất cả đều dành cho mục đích giao tiếp.

Đó là, tôi chưa bao giờ tạo mã tự động từ các sơ đồ và từ quan điểm giao tiếp, tôi thường cố gắng giữ sơ đồ của mình đơn giản và dễ hiểu nhất có thể.

Nhưng khi tôi nhìn vào Visio và Enterprise Architect, có vẻ như họ có nhiều loại biểu đồ, hình dạng, đối tượng thuộc tính khác nhau, hầu hết chúng tôi không sử dụng.

Mọi người có sử dụng UML để làm những việc phức tạp hơn như tạo mã hoặc tạo cơ sở dữ liệu không?

Đúng, các công cụ UML CASE là một trong những mặt hàng nóng của thập niên 90 ... và sau đó không thể cung cấp.

Lý do cơ bản cho điều này là các sơ đồ UML (hoặc hầu hết các loại khác) giúp hiểu vấn đề và / hoặc chương trình giải quyết nó chỉ trong trường hợp sơ đồ đang trừu tượng hóa các chi tiết triển khai của mã thực tế. Do đó (đối với bất kỳ đoạn mã không cần thiết nào), một sơ đồ dễ hiểu vốn dĩ vô dụng đối với việc tạo mã , vì nó thiếu các chi tiết cần thiết. Và ngược lại, một sơ đồ có thể sử dụng trực tiếp để tạo mã không giúp bạn hiểu được chương trình tốt hơn bản thân mã. Nếu bạn đã từng thấy một sơ đồ lớp UML được thiết kế ngược từ mã sản xuất, có lẽ bạn biết ý tôi là gì.

Ngoại lệ tiềm năng duy nhất mà tôi biết là các sơ đồ Mối quan hệ thực thể, không bao gồm mã mỗi se, chỉ (như tên của chúng ngụ ý) các mẩu dữ liệu và các mối quan hệ của chúng. Nhưng tôi chưa bao giờ nghe về một nỗ lực thành công trong việc sử dụng bất kỳ loại sơ đồ UML nào để tạo mã thực [Cập nhật] - tức là nhiều hơn các bộ xương lớp và mã tầm thường như getters / setters -, ngoại trừ trong các công cụ / lĩnh vực mục đích đặc biệt như ORM, như đã được kiểm chứng bởi Doc Brown bên dưới [/ Cập nhật] , và tôi nghĩ rằng đây không phải là ngẫu nhiên.

Cá nhân tôi không ghét UML - Tôi nghĩ rằng sơ đồ UML có thể là một công cụ giao tiếp tuyệt vời - để thể hiện ý định và ý tưởng của bạn trong các cuộc thảo luận thiết kế hoặc để trực quan hóa kiến ​​trúc của ứng dụng của bạn. Nhưng tốt nhất là giữ cho họ làm điều này, và không cố gắng sử dụng chúng cho những thứ họ không giỏi.

Vì vậy, khi tôi ở uni (cách đây một thời gian), tôi được thông báo rằng UML là tương lai, UML sẽ thay thế lập trình và chúng tôi sẽ chỉ tạo mã từ sơ đồ, v.v.

Họ đã sai. Điều đó sẽ xảy ra về thời gian mọi người từ bỏ lời nói và quay trở lại vẽ tranh hang động.

Các vấn đề trong thế giới thực, và các chương trình giải quyết chúng, có một sự phức tạp thiết yếu không thể giảm. Để tạo ra một chương trình làm việc, sự phức tạp đó phải được nắm bắt và thể hiện bằng một số ngôn ngữ thực thi. Câu hỏi là liệu một số ngôn ngữ lập trình sơ đồ có thể hiệu quả hơn một ngôn ngữ lập trình văn bản. Chúng tôi đã thử nghiệm lập trình sơ đồ trong khoảng ba mươi năm, và cho đến nay các bằng chứng được áp dụng rất nhiều trong việc lập trình văn bản. Tôi không biết bất kỳ ứng dụng quan trọng nào được tạo bởi quá trình tạo mã từ các sơ đồ.

KHÔNG

Truyền thuyết dựa trên giả định thất bại rằng viết:

class ClassName extends SomeThing
{

}

... nó khó và cần tự động hóa .

Bạn vẫn có thể tìm thấy tín đồ không thường xuyên, hoặc đám đông tín đồ.
Nhưng đó là cách nó đi với tôn giáo và giáo phái.

Ở đó, không thấy nó quá hữu ích.

Nói chung các sơ đồ đủ cụ thể để tạo một số mã từ chúng, chủ yếu là sơ đồ lớp, không thêm nhiều vào cách hiểu chương trình thực sự và bạn không thể tạo mã từ các sơ đồ tổng quan như trường hợp sử dụng hoặc hoạt động ở cấp độ tổng quan quan trọng cho tài liệu. Một sơ đồ hữu ích để hiểu và có thể có mã được tạo từ đó là biểu đồ trạng thái, rất hữu ích khi bạn thực sự cần máy trạng thái. Nhưng nhìn chung bạn nên cố gắng tránh những thứ đó, vì chúng vốn dễ bị lỗi.

Trong một dự án, chúng tôi được yêu cầu thiết kế mã trong bộ điều chế UML (Rhapsody) và tạo mã từ đó. Nó hoạt động tốt và có lẽ dễ hơn một chút so với việc gõ các tiêu đề (đó là C ++) và các nguyên mẫu bằng tay. Khả năng giữ hai thứ nhất quán tự động có phần tiện dụng.

Các phần thân phương thức vẫn phải được điền bằng tay, vì các sơ đồ thực sự không thể biểu thị điều đó ngoại trừ bộ xương của máy trạng thái.

Mặt khác, nó khá phức tạp, vì vậy bạn phải học rất nhiều thứ bổ sung và quan trọng hơn là đau đớn khi hợp nhất. Hợp nhất được nghiên cứu tốt cho các tệp văn bản và làm việc với chúng, nhưng chưa ai phát minh ra cách dễ dàng để hợp nhất các thay đổi với sơ đồ. Rhapsody thực sự giữ một phần thông tin trong mã được tạo và phân tích lại, vì vậy nó không hoàn toàn không sử dụng được, nhưng nó vẫn là một biến chứng nghiêm trọng.

Mặc dù chắc chắn có thể tạo mã (và thậm chí toàn bộ hệ thống) trực tiếp từ các mô hình UML, tôi chưa bao giờ bắt gặp nó được sử dụng theo cách này.

Theo kinh nghiệm của tôi, hầu hết các công ty dường như sử dụng nó như một công cụ giao tiếp cho các yêu cầu, hoặc "MS Paint để vẽ sơ đồ".

Một điểm khác biệt quan trọng mà tôi muốn đưa ra là hầu hết các công cụ lập mô hình UML cho phép bạn xây dựng một mô hình duy nhất của hệ thống. Ví dụ, Visio có hiểu biết khá tốt về cách UML hoạt động và có nhiều thứ bạn có thể thêm mà không liên quan trực tiếp đến sơ đồ. Các sơ đồ thực tế chỉ đơn giản là các quan điểm khác nhau trên các phần của mô hình, cho phép bạn làm nổi bật các khía cạnh khác nhau của hệ thống.

tất cả (sơ đồ mô hình hóa) là dành cho mục đích giao tiếp

Mô hình hóa có 4 công dụng quan trọng trong quy trình phát triển phần mềm:

1. Công cụ thiết kế tích hợp

2. Công cụ giao tiếp

3. Trợ giúp cho việc tạo ra phần mềm

4. Một cách để giảm sự phức tạp của vấn đề từ thật (tôi đã học được điều này từ phản hồi của @kevin cline ở trên)

5. Quá trình mô hình hóa khiến một số nhà thiết kế suy nghĩ về các chi tiết không được xem xét trong khi mã hóa (và ngược lại). Mô hình hóa tại thời điểm thiết kế cho phép bạn xem xét một bức tranh lớn hơn là mã hóa một phương thức hoặc một lớp bằng ngôn ngữ.

Mô hình hóa theo ý kiến ​​của tôi là rất quan trọng để xây dựng cơ sở dữ liệu (Biểu đồ ER), hiểu các luồng quy trình (Sơ đồ hoạt động) và hiểu các tương tác hệ thống người dùng (sơ đồ ca sử dụng).

Mọi người có sử dụng UML để làm những việc phức tạp hơn như tạo mã hoặc tạo cơ sở dữ liệu không?

Vâng thực sự. ERD (không phải sơ đồ UML) và Sơ đồ lớp có thể được sử dụng (tùy thuộc vào khả năng của công cụ của bạn) để tạo:

1 - Ngôn ngữ định nghĩa dữ liệu (DDL)

2 - Các thủ tục được lưu trữ cho CRUD và Sơ đồ lớp trong ngôn ngữ ưa thích của bạn (ít hữu ích hơn vì các công cụ ORM làm nhiều hơn về điều này)

Trong số các tính năng có giá trị nhất của các công cụ mô hình là:

1 - Khả năng giữ tính toàn vẹn của mô hình. Nếu bạn thay đổi, nó sẽ lan truyền trong mô hình

2 - Khả năng trả lời các câu hỏi được sử dụng ở đâu ('tài khoản' được sử dụng trong mô hình của tôi ở đâu?)

3 - Khả năng cho phép người dùng đồng thời làm việc trên mô hình

4 - Tìm kiếm trong các biểu diễn đồ họa

5 - Kiểm soát in

6 - Phân lớp (sắp xếp các thành phần sơ đồ của bạn theo lớp) để bạn có thể tập trung vào một lớp tại một thời điểm

7 - Tạo mã cơ sở dữ liệu cho một số hệ thống cơ sở dữ liệu

8 - Xác thực mô hình (kiểm tra tính nhất quán, các phím bị thiếu, chu trình, v.v.)

Vì vậy, các công cụ mô hình hóa, đặc biệt là những công cụ tốt, làm được nhiều hơn so với Paint.

Chúng tôi sử dụng Kiến trúc sư phần mềm để thực hiện các thiết kế cấp cao và ghi lại một số tương tác thành phần phức tạp hơn trong công cụ của chúng tôi. Đôi khi chúng tôi tạo ra bộ xương của ứng dụng từ các sơ đồ, nhưng sau khi hoàn thành chúng tôi duy trì cả hai một cách riêng biệt, chúng tôi không cố gắng thiết kế lại mã thành sơ đồ sau khi hoàn tất. Tôi đã từng sử dụng một công cụ có tên Rational XDE hoạt động khá tốt cho các chương trình nhỏ, nhưng nó sẽ bị mất khi bạn bắt đầu thêm vào các trình xử lý sự kiện Swing hoặc thử làm việc với Struts.

Tôi nghĩ rằng một phần lớn lý do tại sao mọi người không viết bằng UML là vì phải mất nhiều công sức hơn để chỉ định hoàn toàn mọi thứ trong UML và sau đó tạo mã từ sơ đồ của bạn. Tôi biết DoD Hoa Kỳ đang làm việc với OMG để phát triển một số công cụ sẽ tạo mã "đã được chứng minh" từ các sơ đồ đã được xác minh chính xác, nhưng ấn tượng của tôi là bạn sẽ kết thúc với một siêu dữ liệu lớn hơn so với mã thực tế. Điều này có thể tốt (rốt cuộc là tài liệu), nhưng việc tạo siêu dữ liệu không nhanh hơn viết mã, vì vậy bạn sẽ dành nhiều thời gian hơn.

Bản thân UML là một hệ thống ký hiệu, vì vậy nó là nguyên nhân cho việc giao tiếp và ghi chép tài liệu. Rất hiếm khi tạo mã từ mô hình UML, nhưng vâng, có những kẻ đang làm điều đó. Người dùng Rhapsody làm điều đó thường xuyên hơn Rose. Điều khó khăn là giữ cho mô hình và mã được đồng bộ hóa, đối với hầu hết các dự án thực tế, chi phí quá cao.

Trong dự án mới nhất của tôi, tôi đang sử dụng UML-Lab (https://www.uml-lab.com). Đây là một công cụ tốt cho phép mô hình được thiết kế ngược lại. Công cụ này tạo mã java và thậm chí các chú thích JPA khá chính xác.

Thách thức cho điều đó là khi làm việc trong một nhóm. Mô hình này là tĩnh và nằm trong một tài nguyên duy nhất khiến cho việc giữ nó đồng bộ với nhiều nhà phát triển thay đổi một chút khó khăn. Có phiên bản dùng thử trong 1 tháng, đây là thời điểm tốt để khám phá và so sánh với những người khác nếu bạn đang điều tra.

Đây là lần đầu tiên tôi thấy một sản phẩm thực hiện mô hình hóa đối tượng và mô hình hóa dữ liệu trong một lần chụp cùng với việc tạo mã.

Mặt khác, trong các dự án trước đây của tôi, tôi luôn thấy các mô hình cũ không chính xác hoặc quá chi tiết.

Trong các dự án trước đây của tôi đôi khi tôi tạo ra các sơ đồ bằng kỹ thuật đảo ngược. Hầu hết thời gian tôi tìm thấy các sơ đồ là lộn xộn và tôi thích vẽ chúng bằng tay lọc tất cả các nhiễu.

Tôi nghĩ rằng chúng ta có thể sử dụng UML để tạo mã. Không phải logic kinh doanh, vì logic kinh doanh không phải là một tiêu chuẩn và thay đổi ứng dụng này sang ứng dụng. Cũng có thể sử dụng sơ đồ lớp cùng với sơ đồ ER để tạo giao diện, lớp, thực thể ngủ đông, phương thức dao cơ bản, v.v. .

Ngoài ra, như đã đề cập trong các bình luận trước, lược đồ cơ sở dữ liệu, tập lệnh DDL, v.v. có thể được tạo bằng các mô hình.

Sử dụng OAW và công cụ mô hình hóa như Enterprise Architect, chúng ta có thể viết các trình tạo mã mạnh hơn, thậm chí có thể giúp tạo các tệp cấu hình, mã nhà máy bằng cách sử dụng các bản mẫu và các giá trị được gắn thẻ.

Tôi vẫn không hiểu tại sao trí tuệ kinh doanh với các công cụ như Business Object có thể phân tích và tận dụng mọi thông tin của công ty trong khi ở cấp độ công nghệ, chúng tôi vẫn chỉ làm việc ở cấp mã hoặc ở mức trừu tượng với UML !!

Vấn đề không phải là UML mà là chuyển đổi mô hình giữa UML và MOF và tạo mã từ sơ đồ clas hoặc xmi bằng các mẫu. UML được cho là đưa ra một cái nhìn trừu tượng về thế giới thực do đó bạn chỉ nhìn thấy những gì thực sự quan trọng. Đã nói rằng làm thế nào để tạo mã chính xác nếu sơ đồ UML chỉ là một cái nhìn về thế giới thực? Do đó, việc phát triển theo mô hình sẽ không thể tạo ra mã từ một mô hình đã thất bại.

Giải pháp là chuyển đổi để ánh xạ thế giới thực và do đó tất cả mã dự án thành một mô hình UML duy nhất. Có một mô hình duy nhất và logic đầy đủ của dự án, sau đó bạn có thể tạo các khung nhìn từ mô hình chứ không phải từ mã mỗi lần. Có một sáng kiến ​​can đảm được thực hiện bởi Omondo trong công nghệ Java / Jee. Khái niệm này được đồng bộ hóa trực tiếp MOF và UML với mã và ORM. Biểu đồ UML bây giờ chỉ là một khung nhìn mức cao của mô hình đang ánh xạ toàn bộ dự án. Bạn có thể tạo hàng trăm lượt xem, thêm hàng trăm ghi chú, v.v .... để hiểu rõ hơn về dự án. Mã sẽ chỉ được tạo nếu phần tử được thay đổi hoặc tạo. Công nghệ kỳ diệu nơi Id Java được ánh xạ tới id UML mà không cần cầu chuyển đổi truyền thống giữa MOF và UML.

Điều tuyệt vời nữa là có thể mô hình hóa miền của tôi ở cấp độ UML và nhận được các chú thích ORM của tôi trực tiếp trong mã và do đó bằng cách sử dụng Hibernate tôi có thể tạo, xóa, tạo cơ sở dữ liệu của mình, triển khai, v.v ... trong tích hợp liên tục vĩnh viễn UML là một phần của tất cả các kiến ​​trúc chứ không phải chính kiến ​​trúc của dự án.

Tôi chưa bao giờ thất vọng bởi UML với tư cách là trình xem cấp cao nếu đồng bộ hóa trực tiếp với mã nhưng hoàn toàn bị tàn phá bởi cách sử dụng MDA truyền thống với việc tạo mã mẫu phát triển theo mô hình. Tạo mã từ một mô hình giống như một trang HTML đến từ một tài liệu từ. Làm thế nào để thay đổi nó một khi nó được tạo ra? Nó chỉ là không thể cập nhật và bạn dành nhiều thời gian để làm sạch mã hơn là viết từ đầu!