Bạn có thường xuyên sử dụng UML chính thức không?

Tôi đã sử dụng MUML đặc biệt (ngôn ngữ mô hình hóa) để thiết kế và giải thích hệ thống khá thường xuyên. Nó trông tương tự như UML và có xu hướng được hiểu khá rõ.

Tuy nhiên, tôi đã có một hoặc hai giáo sư sử dụng UML chính thức, nghiêm ngặt, càng gần với thông số kỹ thuật càng tốt. Tôi luôn nghi ngờ rằng UML nghiêm ngặt không thực sự phổ biến như họ tuyên bố. Vì vậy, làm thế nào bạn có thể thực sự vẽ ra các sơ đồ hoàn chỉnh sử dụng tất cả các kết thúc dòng, bội số, ký hiệu loại thành viên, v.v.

Không bao giờ.

Heck, đã nhiều năm kể từ lần cuối tôi tạo bất kỳ UML nào . Biểu đồ đường trên bảng trắng và mẩu giấy không được tính.

Trên thực tế, chúng tôi chỉ xóa câu hỏi UML duy nhất khỏi hướng dẫn mà chúng tôi sử dụng trong các cuộc phỏng vấn, bởi vì không ai trong chúng tôi thực sự quan tâm đến câu trả lời.

Tôi sử dụng vừa đủ UML (về cả hai loại sơ đồ và nội dung thông tin trong sơ đồ) để đưa ra quan điểm của tôi để cho phép bản thân hoặc người khác thực hiện hệ thống hoặc hệ thống con. Và lý do duy nhất tôi sử dụng UML là vì nó là một tập hợp các biểu tượng được biết đến rộng rãi mà mỗi ý nghĩa đều rất cụ thể, vì vậy không có sự mơ hồ - bất kỳ kỹ sư phần mềm nào cũng có thể nhìn vào sơ đồ và hiểu những gì tôi đang cố gắng nói về hệ thống.

Trớ trêu thay, UML được cho là linh hoạt.

Trong thế giới thực, nó không phải là một bài tập mang tính mô phạm trong việc thực hiện nó một cách đúng đắn. Đó là về giao tiếp hiệu quả và ghi lại một hệ thống / quy trình / ý tưởng.

Để trả lời câu hỏi của bạn, tôi với những người khác. Tôi chưa bao giờ sử dụng đầy đủ UML chính thức, đầy đủ.

Tôi đã sử dụng UML rất thường xuyên trong khoảng bốn năm cho một sản phẩm tạo ra tất cả (hầu hết) bộ xương mã của nó từ Rational Rose.

Năm năm qua đã có nhiều "hộp và mũi tên" chủ yếu được phát minh tại chỗ và thường đủ để có được ý tưởng chung. Chính thức UML chỉ một vài lần trong thời gian này.

Tuy nhiên, tôi đã có một hoặc hai giáo sư sử dụng UML chính thức, nghiêm ngặt, càng gần với thông số kỹ thuật càng tốt.

Hỏi giáo sư của bạn khi nào là lần cuối cùng ông sử dụng phương pháp đó trên một hệ thống thực sự. Nghiêm túc.

Tôi cố gắng trở nên trang trọng nhất có thể khi nói đến UML, nhưng chỉ khi / khi nó có ý nghĩa. Những người quá khích ở cả hai phía của quang phổ (từ những chàng cao bồi cho đến những người theo chủ nghĩa chính thống) đều không hiểu điều đó.

Có những bối cảnh trong đó một cách tiếp cận ít cứng nhắc hơn (như cách bạn sử dụng cá nhân) là cách tiếp cận tốt nhất để làm theo. Một ví dụ điển hình là cho các hệ thống nhỏ hoặc thay đổi, trong đó các yêu cầu nhỏ và không được xác định đầy đủ; nhóm phụ trách là hiệu quả và hiệu quả; điều quan trọng là lấy nó ra hơn là làm cho nó hoàn hảo. Nó được thực hiện lặp đi lặp lại và một số thiếu sót được chấp nhận.

Hoặc có thể bạn đang ở trong một giai đoạn mà bạn đang làm khách mời và phác thảo trái ngược với giai đoạn mô hình hóa chính thức đầy đủ. Đó là những ví dụ sẽ đến với tâm trí.

Vào những lúc khác, bạn cần một cách tiếp cận UML chính thức cứng nhắc. Ví dụ, bạn có thể bị ràng buộc theo hợp đồng; bạn có một số lượng lớn các nhà phát triển trong nhiều nhóm (có thể được phân phối); phạm vi của dự án có thể tính bằng năm; nó là một hệ thống rất lớn (bao gồm các thành phần phần mềm và phần cứng); chi phí thất bại cao, v.v.

Vào những lúc khác , bạn phải sử dụng một cái gì đó khác thay thế / ngoài UML (các mô hình chính thức toán học thực tế như lưới petri, CSP hoặc logic tạm thời.) Ví dụ về điều này là các hệ thống thời gian thực, các hệ thống trong đó các sự cố là thảm họa (thiết bị y tế) hoặc nơi bạn bị ràng buộc theo hợp đồng (.ie. như ở châu Âu khi phát triển hệ thống giao thông.)

Tất cả phụ thuộc vào hoàn cảnh và những gì chúng ta mong đợi đạt được từ mỗi phương pháp. Một giáo sư nói về việc gắn bó với hình thức chỉ đơn giản là một người nhiệt thành mù quáng. Thế giới kỹ thuật không phải là sự phân đôi đen trắng, đúng / sai. Đó là một thế giới của sự đánh đổi thông minh.

Nếu bạn đủ thông minh để sử dụng một mô hình ngẫu nhiên, không chính thức theo cách hiệu quả và phù hợp để hoàn thành công việc, thì cũng vậy. Với cùng một mã thông báo, bạn sẽ được nhận ra khi KHÔNG sử dụng phương pháp tiếp cận không chính thức và / hoặc khi KHÔNG sử dụng phương thức chính thức.

Phải nói rằng, bạn phải chơi nó bằng tai với các giáo sư. Cung cấp cho họ một xương để họ cho bạn một điểm, và nếu điều đó có nghĩa là cuối cùng phải cúi đầu trước câu thần chú nhiệt tâm của họ, điều đó tốt. Bạn biết những gì làm việc cho bạn, và hy vọng, bạn sẽ biết khi nào nên sử dụng những gì và làm thế nào trong thế giới thực.

Là một phần trong nghiên cứu tiến sĩ của tôi, tôi đã nghiên cứu cách các nhà thiết kế có kinh nghiệm sử dụng UML trong hợp tác thiết kế (Mặc dù trong các thiết lập nhân tạo).

Phát hiện của tôi là các phép ẩn dụ và ký hiệu UML được mượn, nhưng có rất ít sự tuân thủ tính nghiêm ngặt của các công cụ.

Sau này, một số mô hình có thể được chuyển đổi lặp lại thành UML nghiêm ngặt hơn, thường là khi một công cụ CASE đòi hỏi có liên quan cho mục đích tạo mã.

Tất nhiên, hãy cẩn thận áp dụng nghiên cứu học thuật :)

Một liên kết đến bản tóm tắt giấy và bản thân giấy (nếu bạn không có quyền truy cập ACM) .

Bên cạnh đó, tôi đánh giá cao "Mô hình hóa nhanh" của Ambler's.

Chúng tôi sử dụng UML chính thức để tạo mã ORM ngủ đông. Hầu hết những thứ khác là bảng không chính thức hoặc bảng trắng. Nó chỉ quan trọng đối với chúng tôi với việc tạo mã bởi vì sự thiếu hình thức sẽ phá vỡ nó.

Nó phụ thuộc vào ngành nghề mà bạn tham gia. Nếu bạn làm việc cho những khách hàng yêu cầu đánh giá kỹ thuật thường xuyên (ví dụ: PDR, CDR, v.v.) thì họ thích một số loại tiêu chuẩn hóa hơn là các hệ thống công chứng đặc biệt. Trong công việc của chính phủ đặc biệt. Nó ngăn chặn thông tin sai lệch và giải thích 15 phút ban đầu về ký hiệu mà bạn đã phát minh ra.

Ngoài ra, chỉ vì bạn đang sử dụng UML không có nghĩa là bạn phải chấm mỗi i và vượt qua mọi t theo tiêu chuẩn. Điều đó chỉ khi bạn muốn thực hiện một số loại tạo / thực thi mã tự động. Tôi không biết ai đã làm điều đó cho hơn 1 dự án.

Mặt khác, nếu bạn chỉ làm việc cho công ty của mình với một nhóm các nhà phát triển của riêng bạn thì ai quan tâm bạn sử dụng ký hiệu nào. Mặc dù, nếu bạn chọn đúng công cụ thì đó có thể là một trình tiết kiệm thời gian thực.

Với tất cả những gì đã nói, bạn sẽ khó có thể tham gia vào một số ngành mà không thể thiết kế bằng UML. Trong các ngành công nghiệp khác, bạn sẽ không bao giờ nhìn thấy nó.

Ngoài ra, tôi nghĩ rằng bạn cũng sẽ tìm thấy mối tương quan giữa các ngành đòi hỏi thiết kế phải đúng vì chi phí hiệu chỉnh tương ứng cao khi là người dùng UML nặng; so với các ngành mà chi phí sửa lỗi thiết kế ít hơn nhiều so với thay đổi tài liệu / mã vì là nơi mà UML có thể không bao giờ được sử dụng.

Liên quan đến câu hỏi ban đầu. Hầu hết các trường đại học có xu hướng hướng đến việc đào tạo sinh viên của họ cho các công ty tuyển dụng sinh viên của họ thường xuyên nhất. Nếu giáo sư của bạn nghĩ rằng UML là quan trọng thì điều đó sẽ không làm tôi ngạc nhiên khi nhiều doanh nghiệp tuyển dụng từ trường của bạn sử dụng UML. Vì vậy, bạn nên học cách sử dụng nó.

Khi tôi đọc về UML, tôi đã thử điều này trên tất cả các vấn đề mà tôi đã giải quyết trong khóa học C ++ của mình. Fortunatly một trong những ví dụ đầu tiên tôi đã thử là mô tả một danh sách được liên kết.
Không hoạt động.
Điều đó nói rằng, cùng với một quy trình mô hình hóa tốt UML là hữu ích. Chỉ vì nó là tốt hơn hoặc xấu hơn một tiêu chuẩn.
Tôi rất thích xem một ngôn ngữ mô tả về lập trình meta mẫu. Tôi nghĩ rằng điều đó sẽ giúp ích rất nhiều trong việc hiểu những gì đang diễn ra trong <<< >>>> -land

UML thật đau đớn nếu bạn cũng thử phát triển Model Driven. Ý tôi là UML chỉ là một ký hiệu đồ họa rất hữu ích và mọi thứ khác đều vô dụng. Tôi không chi tiêu cho việc lập mô hình nhưng sử dụng UML mỗi ngày để tạo cấu trúc cho các dự án của mình. Những gì tôi làm là nhanh chóng vẽ sơ đồ usecase cơ bản ở các mức yêu cầu, sau đó chuyển ngay sang sơ đồ lớp. Tôi thêm truy xuất nguồn gốc yêu cầu giữa sơ đồ usecase và lớp. Sơ đồ lớp của tôi cũng tạo mã vì nó được đồng bộ hóa trực tiếp. Không có thẻ nào trong mã tất cả mô hình được lưu trong mô hình UML được ánh xạ tới dự án Java.

Tôi tạo bộ xương cho ứng dụng của mình với một vài sơ đồ lớp, sau đó chuyển sang mã. Sau khi hoàn thành mã, tôi hợp nhất nó với mô hình. Nó là một kiểu lặp giữa mã và mô hình trong đó mã chạy mô hình. Vì vậy, sơ đồ lớp của tôi cung cấp cho tôi mức độ trừu tượng cao hơn và mã của tôi trong khi mã của tôi cho tôi triển khai logic nghiệp vụ (ví dụ: các phương thức).

Mô hình hóa UML cần ít hơn 10 phút mỗi ngày, được thực hiện khi tôi cần thời gian để suy nghĩ những gì tôi cần phát triển và làm thế nào.

UML là tuyệt vời, tuyệt vời và thực sự hữu ích nhưng phát triển theo mô hình là vô ích !!

Nếu tôi đang ghi lại một hệ thống mà chúng tôi đã triển khai, thì tôi sẽ cố gắng đặt nó xuống với UML chính thức đầy đủ. Nhưng thời gian còn lại, tôi chỉ sử dụng bao nhiêu là cần thiết để có được ý tưởng. Tôi cũng thấy mình sử dụng nhiều DFD hơn UML, vì chúng có vẻ phù hợp hơn với các hệ thống chúng tôi thiết kế gần đây.

Tôi vừa rời khỏi trường đại học được cho là hàng đầu của mình (ít nhất là tạm thời) vì sự khăng khăng cứng nhắc của họ đối với các hoạt động mô hình hình ảnh quá tốn thời gian, công việc diễn đàn, những thứ kỹ năng mềm dư thừa mà bất cứ ai lớn lên xung quanh máy tính hoặc đã từng suy nghĩ đối với một giao diện người dùng sẽ đủ tốt để ý nghĩ đi sâu vào nợ nần sẽ khiến người ta muốn phá vỡ mọi thứ trong sự thất vọng hoàn toàn.

Tôi đã phải lựa chọn giữa việc học những gì tôi thấy những công việc cấp độ đầu vào và cấp cơ sở yêu cầu và những gì CES đặt ra cho chứng nhận ABET của trường đại học, khiến những người ra quyết định chơi ngớ ngẩn khi có những vấn đề khó khăn với những hạn chế về thời gian và những kỳ vọng không thực tế mà một đánh giá PERT sẽ tiết lộ. Các trường đại học không thực hành những gì nó dạy.

Theo tôi, Quy trình hợp nhất có rất nhiều công đức, nhưng toàn bộ thực hành đúc các tạo tác trực quan, những gì từng có ngôn ngữ mô hình hóa là một chút vô lý. Một tài liệu được tinh chỉnh lặp có chứa một danh sách có răng cưa, chẳng hạn như có thể được tạo bằng Word, Workflowy, Evernote, OpenOffice hoặc đặt tên cho một trình xử lý văn bản hoàn toàn có khả năng ghi lại những gì được yêu cầu bởi Quy trình hợp nhất. Một cái gì đó đơn giản này có thể dễ dàng được làm việc bởi nhiều người dùng, được kiểm soát phiên bản và nếu một người chọn đúng công cụ để thực hiện, một nhóm thậm chí có thể làm việc cùng lúc. Điều này được thực hiện dễ dàng hơn nhiều so với khi UML dường như là một chế độ cần thiết để hợp nhất các nhóm.