Lợi ích của việc mô hình hóa các hệ thống phần mềm so với thực hiện tất cả trong mã là gì?

Hầu hết, nếu không phải tất cả những người CNTT mà tôi biết đều tin rằng việc mô hình hóa phần mềm bằng UML hoặc các loại sơ đồ khác trước khi mã hóa là có lợi. (Câu hỏi của tôi không phải là về UML cụ thể, nó có thể là bất kỳ mô tả đồ họa hoặc văn bản nào của thiết kế phần mềm.)

Tôi không chắc chắn về nó. Lý do chính là: Mã không nói dối. Nó được kiểm tra bởi trình biên dịch hoặc trình thông dịch. Nó hy vọng có các bài kiểm tra tự động và cần phải vượt qua phân tích mã tĩnh. Nếu một mô-đun không giao tiếp chính xác với một mô-đun khác, nó thường rõ ràng trong mã vì bạn nhận được thông báo lỗi.

Tất cả điều này không thể được thực hiện với sơ đồ và các tài liệu khác. Vâng, có những công cụ kiểm tra UML, nhưng mọi thứ tôi thấy cho đến nay đều rất hạn chế. Do đó, các tài liệu này có xu hướng không đầy đủ, không nhất quán hoặc giả lập.

Ngay cả khi các sơ đồ là nhất quán, bạn không thể chắc chắn rằng mã thực sự thực hiện chúng. Vâng, có các trình tạo mã, nhưng chúng không bao giờ tạo ra tất cả các mã.

Đôi khi tôi cảm thấy như nỗi ám ảnh với kết quả mô hình hóa từ giả định rằng mã chắc chắn phải là một mớ hỗn độn khó hiểu mà các kiến ​​trúc sư, nhà thiết kế hoặc những người được trả lương cao khác có được bức tranh lớn không cần phải giải quyết. Nếu không, nó sẽ trở nên quá đắt. Do đó, tất cả các quyết định thiết kế nên được di chuyển ra khỏi mã. Bản thân mã phải được để lại cho các chuyên gia (khỉ mã), những người có khả năng viết (và có thể đọc) nó nhưng không phải đối phó với bất cứ điều gì khác. Điều này có lẽ có ý nghĩa khi trình biên dịch là lựa chọn duy nhất, nhưng các ngôn ngữ hiện đại cho phép bạn viết mã ở mức độ trừu tượng rất cao. Vì vậy, tôi không thực sự thấy sự cần thiết của mô hình nữa.

Tôi thiếu những lập luận nào cho việc mô hình hóa các hệ thống phần mềm?

Bằng cách này, tôi tin rằng sơ đồ là một cách tuyệt vời để tài liệu và giao tiếp một số khía cạnh của thiết kế phần mềm nhưng điều đó không có nghĩa là chúng ta nên căn cứ thiết kế phần mềm trên chúng.

Làm rõ:

Câu hỏi đã được giữ lại là không rõ ràng. Vì vậy, hãy để tôi thêm một số lời giải thích:

Tôi đang hỏi liệu có hợp lý khi sử dụng các tài liệu (không phải mã) mô hình hóa phần mềm như là nguồn chính của sự thật về thiết kế phần mềm. Tôi không có trường hợp nào trong đó một phần đáng kể của mã được tạo tự động từ các tài liệu này. Nếu đây là trường hợp, tôi sẽ coi các tài liệu là mã nguồn chứ không phải là một mô hình.

Tôi đã liệt kê một số nhược điểm của quy trình này khiến tôi tự hỏi tại sao rất nhiều người (theo kinh nghiệm của tôi) coi nó là cách tốt nhất để thiết kế phần mềm.

Lợi ích của việc mô hình hóa các hệ thống phần mềm so với tất cả trong mã là: Tôi có thể điều chỉnh mô hình trên bảng trắng.

Tôi là một người tin tưởng lớn vào phép thuật giao tiếp trên một tờ giấy. Nếu tôi đã cố gắng đặt mã lên bảng trắng, khi dạy hệ thống của chúng tôi cho các lập trình viên mới, đơn giản là không có mã nào ở mức độ trừu tượng cần thiết phù hợp với bảng trắng.

Tôi biết nỗi ám ảnh với nghề người mẫu mà bạn đang đề cập đến. Mọi người làm việc vì đó là cách họ đã được thực hiện trước đây, mà không nghĩ về lý do tại sao họ làm việc đó. Tôi đã gọi nó là chủ nghĩa hình thức. Tôi thích làm việc không chính thức vì khó che giấu sự điên cuồng đằng sau truyền thống.

Điều đó không có nghĩa là tôi sẽ không xóa bản phác thảo UML ngay bây giờ. Nhưng tôi sẽ không bao giờ là người yêu cầu bạn bật tài liệu UML trước khi bạn có thể viết mã. Tôi có thể yêu cầu bạn mất 5 phút và tìm MỘT SỐ cách để giải thích những gì bạn đang làm vì tôi không thể chịu được sự tồn tại của mã mà chỉ một người hiểu.

Fowler đã xác định những cách khác nhau mà mọi người sử dụng UML mà ông gọi là chế độ UML . Điều nguy hiểm với tất cả chúng là chúng có thể được sử dụng để che giấu khỏi việc làm hữu ích. Nếu bạn đang thực hiện mã hóa bằng chuột, thì tôi cũng đã thấy nhiều lần thử. Không thấy ai làm việc đó thực sự hiệu quả. Nếu bạn đang làm điều đó để giao tiếp, bạn nên chắc chắn rằng người khác hiểu bạn. Nếu bạn đang làm điều đó để thiết kế thì tốt hơn hết là bạn nên tìm và sửa các vấn đề khi bạn làm việc. Nếu mọi thứ đều suôn sẻ và phần lớn thời gian của bạn dành cho việc làm cho mũi tên trông đẹp thì hãy gõ nó đi và quay lại làm việc.

Quan trọng nhất, không tạo ra các sơ đồ mà bạn mong đợi có giá trị hơn một ngày. Nếu bạn bằng cách nào đó có thể, bạn đã thất bại. Bởi vì phần mềm có nghĩa là mềm mại. Đừng dành hàng tuần để có được sơ đồ vừa phải. Chỉ cần cho tôi biết những gì đang xảy ra. Nếu bạn phải, sử dụng một chiếc khăn ăn.

Điều đó nói rằng, tôi thích các lập trình viên biết UML và các mẫu thiết kế của họ. Họ dễ dàng giao tiếp hơn. Miễn là họ biết rằng sản xuất sơ đồ không phải là một công việc toàn thời gian.

Tôi đang hỏi liệu có hợp lý không khi sử dụng các tài liệu (không phải mã) mô hình hóa phần mềm làm nguồn chính của sự thật về thiết kế phần mềm

Không. Điều này không bao giờ có ý nghĩa. Mã của bạn là tài liệu thiết kế chính của bạn, tức là "nguồn sự thật chính về thiết kế phần mềm". Chỉ mã mô tả chính xác những gì ứng dụng làm khi trình biên dịch lấy thiết kế đó và tạo ứng dụng từ nó.

Bằng mọi cách, hãy sử dụng sơ đồ làm tài liệu thiết kế bổ sung, mặc dù nếu chúng không được tạo tự động từ mã, hãy coi chừng chúng kể một câu chuyện khác với thiết kế thực. Nếu UML nổi thuyền của bạn, hãy sử dụng nó. Nếu không, sử dụng một cái gì đó khác.

Một số người dân thấy hữu ích khi phác thảo suy nghĩ của họ dưới dạng sơ đồ trước khi bắt đầu viết mã. Nhưng hãy nhớ những gì chú Bob đã nói về vấn đề này:

" Vì vậy, vâng, sơ đồ có thể không phù hợp vào thời điểm nào. Khi nào chúng không phù hợp? Khi bạn tạo chúng mà không có mã để xác thực chúng, và sau đó có ý định theo dõi chúng. Không có gì sai khi vẽ sơ đồ để khám phá một ý tưởng. "

Nếu bạn sử dụng UML để khám phá một thiết kế, hãy vứt chúng đi khi bạn bắt đầu viết mã. Viết một bài kiểm tra, sau đó viết một số mã để làm cho nó vượt qua. Nói lại. Bằng cách đó, bạn sẽ kết thúc với một thiết kế được xác nhận. UML không bao giờ có thể cung cấp cho bạn cùng mức xác nhận thiết kế của bạn.

Hầu hết, nếu không phải tất cả những người CNTT mà tôi biết đều tin rằng việc mô hình hóa phần mềm bằng UML hoặc các loại sơ đồ khác trước khi mã hóa là có lợi.

Tôi không đồng ý rằng tất cả những người bạn biết đều tin điều này, nhưng tôi không nghĩ nó nhất thiết phải phổ biến trên bảng. Năm 1970, Winston Royce biết rằng phát triển phần mềm có một số mức độ lặp lại giữa các hoạt động thiết kế và mã. Năm 1992, Jack Reeves đã viết về tiền mã hóa là hoạt động thiết kế thực sự (cũng được thảo luận trên C2 Wiki ).

Điều này không có nghĩa là mọi người đã cố gắng tạo ra các công cụ phát triển theo mô hình. Có các công cụ cố gắng tạo mã từ các mô hình UML (và không chỉ các sơ đồ lớp, mà còn liên kết các loại sơ đồ khác nhau với nhau và tạo mã từ chúng). Nhưng những thứ đó, ít nhất là từ những gì tôi đã thấy, các công cụ được sử dụng rộng rãi.

Điều này cũng không có nghĩa là bạn nên chuyển ngay từ yêu cầu sang viết mã. Có một số quyết định thiết kế nhất định rất quan trọng để có được sớm và một số mức độ mô hình hóa có thể hữu ích để đảm bảo rằng mọi người đều hiểu các tùy chọn, tác động của chúng và có thể giao tiếp. Một số người (bao gồm cả tôi) gọi đây là "kiến trúc phần mềm" .

Mã không nói dối. Nó được kiểm tra bởi trình biên dịch hoặc trình thông dịch. Nó hy vọng có các bài kiểm tra tự động và cần phải vượt qua phân tích mã tĩnh. Nếu một mô-đun không giao tiếp chính xác với một mô-đun khác, nó thường rõ ràng trong mã vì bạn nhận được thông báo lỗi.

Đây thực sự là trung tâm của một số khía cạnh của Mô hình hóa Agile, đặc biệt là Thông số kỹ thuật thực thi và Nguồn thông tin duy nhất . Tôi không nhất thiết phải đồng ý với TDD, nhưng ý tưởng có mã của bạn và các bài kiểm tra liên quan (từ đơn vị thông qua các bài kiểm tra chấp nhận, tốt nhất là được chụp dưới dạng kiểm tra tự động) là nguồn duy nhất của sự thật là một ý tưởng tốt.

Ngay cả khi các sơ đồ là nhất quán, bạn không thể chắc chắn rằng mã thực sự thực hiện chúng. Vâng, có các trình tạo mã, nhưng chúng không bao giờ tạo ra tất cả các mã.

Tôi nghĩ như một quy tắc chung, đi từ mô hình-> mã là sai cách. Thay vào đó, mã nên tạo mô hình. Đó là, các công cụ sẽ có thể kiểm tra mã và tạo các biểu diễn dạng bảng và dạng bảng có thể được tăng cường hơn nữa khi các kỹ sư viết văn bản xung quanh chúng. Và thế hệ mô hình từ mã này phải là một phần liền mạch của quá trình xây dựng và phát hành.

Có những công cụ, ở các mức độ khác nhau, hỗ trợ điều này cho các ngôn ngữ khác nhau. Với bản chất của ngôn ngữ và mô thức, nó dễ dàng hơn đối với một số ngôn ngữ khác.

Tôi đã liệt kê một số nhược điểm của quy trình này khiến tôi tự hỏi tại sao rất nhiều người (theo kinh nghiệm của tôi) coi nó là cách tốt nhất để thiết kế phần mềm.

Tôi không nghĩ rằng những người này nhất thiết phải hiểu về công nghệ phần mềm và thiết kế phần mềm. Tôi nghĩ rằng những người này đang xem xét những gì các ngành kỹ thuật khác làm và ánh xạ nó tới những điều mà họ nghĩ rằng các kỹ sư phần mềm nên làm. Nhưng họ đang bỏ qua một sự khác biệt lớn. Các ngành kỹ thuật khác tạo ra các mô hình và mô phỏng trước tiên vì nó cực kỳ tốn kém và mất thời gian để xây dựng sản phẩm thực tế. Trong công nghệ phần mềm, chúng ta có thể lấy các phần của thiết kế và tạo ra thứ gì đó có thể kiểm chứng được trong môi trường thế giới thực trong thời gian rất ngắn và chi phí rất ít. Kinh tế rất khác nhau.

Lợi ích của việc mô hình hóa các hệ thống phần mềm so với thực hiện tất cả trong mã là gì?

Khi bạn có một hệ thống phần mềm cực kỳ phức tạp, có các mô hình có nghĩa là có một cái gì đó dễ hiểu hơn. Đó là một mức độ trừu tượng khác nhau, một cái gì đó giúp mọi người hiểu các khía cạnh khác nhau của hệ thống của bạn. Đó là một trong những lý do tại sao có rất nhiều ngôn ngữ mô hình hóa và các loại mô hình khác nhau được cho phép bởi mỗi ngôn ngữ mô hình hoặc ký hiệu - để cho phép các bên liên quan khác nhau hiểu, về mặt khái niệm, hệ thống phần mềm một cách nhanh chóng và dễ dàng.

Tôi đang hỏi liệu có hợp lý khi sử dụng các tài liệu (không phải mã) mô hình hóa phần mềm như là nguồn chính của sự thật về thiết kế phần mềm. Tôi không có trường hợp nào trong đó một phần đáng kể của mã được tạo tự động từ các tài liệu này. Nếu đây là trường hợp, tôi sẽ coi các tài liệu là mã nguồn chứ không phải là một mô hình.

Rất nhiều tài liệu không phải là mã hữu ích như bản thiết kế . Đó là, "sự thật" của thiết kế nên theo hướng này. Đó là một cách để mô hình hóa các yếu tố mà một thiết kế phải đáp ứng. Bạn có thể gọi chúng là các tài liệu yêu cầu, nhưng điều đó có thể quá mạnh trong tất cả các ví dụ tôi có thể đưa ra. Tôi đã sử dụng PlantUML thông qua PlantText.com để sản xuất những thứ này.

• Sơ đồ ca sử dụng có thể hiển thị các tính năng và tương tác dự định với người dùng hoặc hệ thống bên ngoài.

• Sơ đồ hoạt động có thể hiển thị các quy trình kinh doanh mà một phần mềm cần hỗ trợ.

• Biểu đồ trạng thái có thể hiển thị dự định động trên một trang web:

• Các mẫu thiết kế của Gang of Four được trình bày dưới dạng mô hình tĩnh và động. Ví dụ: Memento:
  
  

Tôi đã liệt kê một số nhược điểm của quy trình này khiến tôi tự hỏi tại sao rất nhiều người (theo kinh nghiệm của tôi) coi nó là cách tốt nhất để thiết kế phần mềm.

Nếu bạn quan tâm đến một số thông tin thực sự về việc sử dụng UML ngoài kinh nghiệm của bạn, có một số nghiên cứu đã được thực hiện (Tôi đã cố gắng tìm liên kết đến các bài viết không phải trả tiền):

• Petre, Mary (2013). UML trong thực tiễn . Trong: Hội nghị quốc tế về Kỹ thuật phần mềm lần thứ 35 (ICSE 2013), ngày 18-26 tháng 5 năm 2013, San Francisco, CA, Hoa Kỳ, trang 722 Lỗi731.
• N. Mangano, TD LaToza, M. Petre và A. van der Hoek (2015). Cách các nhà thiết kế phần mềm tương tác với các bản phác thảo tại Bảng trắng . Trong: Giao dịch của IEEE về Kỹ thuật phần mềm, tập. 41, không 2, trang 135-156.
• Andrew Forward và Timothy C. Lethbridge. 2008. Các vấn đề và cơ hội để phát triển phần mềm tập trung vào mô hình so với tập trung vào mã: một cuộc khảo sát các chuyên gia phần mềm . Trong Kỷ yếu của hội thảo quốc tế năm 2008 về Mô hình trong công nghệ phần mềm (MiSE '08). ACM, New York, NY, Hoa Kỳ, 27-32.

Chúng tôi các nhà phát triển thích sử dụng hình ảnh để giải thích thế giới của chúng tôi, vì vậy đây là một trong những sản xuất xe hơi:

• Chiếc xe là kết quả của chuỗi sản xuất, tương tự cho mã (tất nhiên thêm quá trình triển khai).
• Tài liệu thiết kế của xe giống như tài liệu thiết kế của phần mềm.

Trong thế giới của chúng ta, điều đó thường xảy ra hơn những người quan niệm và tạo ra tài liệu thiết kế giống với người tạo ra mã. Điều đó không đúng trong các lĩnh vực khác. Tuy nhiên, điều đó không có nghĩa là bạn thực sự có thể có được cùng một mức chất lượng bằng cách làm tất cả chúng cùng nhau.

Bằng cách tạo các tài liệu đó trước mà không cần mã hóa (không bao gồm bất kỳ thứ gì như bằng chứng về khái niệm cho tính linh hoạt, ...):

• Bạn chắc chắn suy nghĩ trước khi làm, mã hóa một khi bạn biết những gì bạn phải làm là DỄ DÀNG.
• Bạn có thể đặt những người có kinh nghiệm hơn tập trung vào phần khó nhất trong phần mềm của bạn: thiết kế, thuật toán / toán học là bất kỳ mục đích nào ngoại trừ cho mục đích rất cụ thể (nhúng, thời gian thực, lắp ráp).
• Bạn có thể ủy thác cho những người ít kinh nghiệm hơn một phần tốt của quy trình mã hóa trong khi những người có kinh nghiệm hơn chỉ tập trung vào phần quan trọng nhất của anh ta cần mức độ kỹ năng của họ. Những người ít kinh nghiệm sẽ học được rất nhiều về điều đó.
• Bạn có thể thảo luận với những người không phải CNTT thông qua hình ảnh của tài liệu thiết kế của bạn, trong khi nếu bạn chỉ có mã, bạn sẽ phải trích xuất một hình ảnh về những gì bạn đã làm, với tất cả rủi ro để quên một cái gì đó (một người nghe bị lãng quên ở đâu đó ...). Xem câu trả lời của CandiedOrange để biết thêm khía cạnh về giao tiếp.
• Khi bạn phải làm cho phần mềm của mình phát triển, bạn có thể dự đoán tốt hơn những gì sẽ tác động.
• Thiết kế sẽ giúp dễ dàng cắt phần mềm của bạn xuống và phần của phần mềm của bạn được phát triển đồng thời.
• Viết các bài kiểm tra đơn vị reberbative chết tiệt đó sẽ dễ dàng hơn khi bạn không phải đau đầu về việc bao gồm tất cả các trường hợp trong khi mã hóa chúng, theo cách tiếp cận TDD mã hóa bài kiểm tra trước khi mã dễ dàng.
• ...

Lưu ý: những xác nhận này cho rằng mã thực sự là sự phản ánh của thiết kế và cả hai đều được cập nhật ...