Tại sao tất cả chúng ta không thực hiện phát triển theo mô hình? [đóng cửa]

Tôi là một người tin tưởng thực sự vào Phát triển theo mô hình, tôi nghĩ rằng nó có khả năng tăng năng suất, chất lượng và dự đoán. Khi nhìn vào MetaEdit , kết quả thật tuyệt vời. Mạc ở Hà Lan đang phát triển rất rất nhanh và có kết quả tuyệt vời.

Tôi cũng biết có rất nhiều vấn đề

• phiên bản của máy phát điện, mẫu và khung
• các dự án không phù hợp để phát triển theo mô hình (không đủ sự lặp lại)
• rủi ro cao hơn (khi dự án đầu tiên thất bại, bạn có ít kết quả hơn bạn có với sự phát triển truyền thống hơn)
• Vân vân

Nhưng những vấn đề này dường như vẫn có thể giải quyết được và lợi ích sẽ vượt xa nỗ lực cần thiết.

Câu hỏi : Bạn thấy điều gì là vấn đề lớn nhất khiến bạn thậm chí không xem xét phát triển theo mô hình?

Tôi muốn sử dụng những câu trả lời này không chỉ cho sự hiểu biết của riêng tôi mà còn là một nguồn có thể cho một loạt các bài báo nội bộ tôi dự định viết.

Không có búa vàng. Những gì hoạt động tốt trong một lĩnh vực là khá vô dụng trong một lĩnh vực khác. Có một số phức tạp vốn có trong phát triển phần mềm và không có công cụ ma thuật nào sẽ loại bỏ nó.

Người ta cũng có thể lập luận rằng việc tạo mã chỉ hữu ích nếu bản thân ngôn ngữ (hoặc khung) không đủ trình độ cao để cho phép các khái niệm trừu tượng mạnh mẽ khiến MDD trở nên vô nghĩa.

Câu hỏi thú vị! Tôi thừa nhận, tôi không phải là một người hâm mộ, nhưng sau đó tôi đã cố gắng sử dụng phát triển theo mô hình nhiều lần trong các dự án phù hợp với một số vấn đề bạn vừa nêu.

Đây là danh sách lý do của tôi:

• đường cong học tập - các công cụ mô hình hóa đã phát triển rất nhanh, đến nỗi tôi khó tìm được các kỹ sư hiểu sâu về công cụ này. Tôi vẫn thấy bạn chỉ tốt như công cụ mô hình của bạn. Phải thừa nhận rằng, nhiều vấn đề dưới đây có thể theo dõi lại vấn đề này - bất cứ khi nào bạn nghĩ rằng một công cụ quá hạn chế, có thể bạn không biết rõ về nó.
• Quá cấu trúc - Cá nhân tôi đã ở trong những tình huống mà tôi thấy rằng công cụ mô hình hóa đơn giản là quá cấu trúc để cho phép tôi mô tả mọi thứ tôi cần để mô tả. Và một khi tôi chuyển sang vẽ một số mẫu của mô hình bên ngoài công cụ, mọi thứ sẽ nhanh chóng phân rã khi mọi người bắt đầu trôi ra ngoài công cụ để tìm thông tin.
• Chi phí điều chỉnh công cụ - mỗi lần tôi cố gắng tự động tạo mã, tôi đã kết thúc việc làm lại mã theo cách thủ công một khi tôi thấy công cụ nghĩ gì là đúng. Tôi biết sau một vài lần đi loanh quanh, vấn đề này giảm dần, nhưng điều đó có nghĩa là bạn phải sống sót sau vài vòng đầu tiên. Tôi thường cảm thấy rằng chúng tôi đã chơi một nốt ruồi - tạo mô hình -> tạo mã -> sửa mã -> cập nhật mô hình -> sửa mô hình, rửa và lặp lại.
• Quản lý cấu hình mô hình - do mô hình mô tả các phần lớn của dự án, ở một mức độ nào đó, mô hình CM sẽ được cắt chéo nhiều hơn so với mã được xây dựng. Tự mình sắp xếp các tệp mô hình hóa là một nghệ thuật - làm sai và bạn thường kết thúc với sự bế tắc của nhà phát triển hoặc các mô hình lỗi thời khi mọi người từ bỏ và đi xuống mã.
• Thời gian để tiếp thị - Tôi đã trải qua những vấn đề nhất định khi trong tình huống nhu cầu về phần mềm làm việc là cấp bách. Nếu dự án và nhóm đủ nhỏ, tôi thấy không có lý do gì để lãng phí thời gian cho một công cụ mô hình hóa khi thời gian có thể được dành cho mã hóa và thử nghiệm. Không phải mọi dự án đều đủ lớn để yêu cầu đầu tư như vậy.
• Chi phí thất bại - khi tôi thấy các dự án chạy trốn khỏi các công cụ mô hình hóa, đó là do chi phí thất bại cao - để sử dụng các công cụ này, bạn cần mọi nhà phát triển tham gia. Đó là một sự đầu tư lớn vào đào tạo và thực hành học tập, và một sai lầm rất tốn kém nếu ai đó đã thiết lập mô hình tồi tệ. Kinh nghiệm của tôi là có thể mất hai hoặc ba bản phát hành để có được mô hình đúng - rất nhiều dự án không tồn tại những lỗi mô hình đủ lâu để nhận ra lợi ích.

Nó đã được trích dẫn, nhưng No Silver Bullet giải quyết vấn đề khá rõ:

Bản chất của một thực thể phần mềm là một cấu trúc của các khái niệm đan xen: tập dữ liệu, mối quan hệ giữa các mục dữ liệu, thuật toán và các hàm của hàm. Bản chất này là trừu tượng ở chỗ một cấu trúc khái niệm như vậy là giống nhau dưới nhiều cách trình bày khác nhau. Tuy nhiên, nó rất chính xác và rất chi tiết.

Tôi tin rằng phần khó của việc xây dựng phần mềm là đặc điểm kỹ thuật, thiết kế và thử nghiệm của cấu trúc khái niệm này, chứ không phải lao động để thể hiện nó và kiểm tra tính trung thực của biểu diễn. Chúng tôi vẫn mắc lỗi cú pháp, để chắc chắn; nhưng chúng là fuzz so với các lỗi khái niệm trong hầu hết các hệ thống.

Nếu điều này là đúng, việc xây dựng phần mềm sẽ luôn khó khăn. Không có viên đạn bạc.

Sau đó, Brooks chỉ ra những điều sau đây về khái niệm "lập trình tự động":

Trong gần 40 năm, mọi người đã dự đoán và viết về "lập trình tự động" hoặc tạo ra một chương trình để giải quyết vấn đề từ một tuyên bố về các đặc tả vấn đề. Một số ngày nay viết như thể họ mong đợi công nghệ này sẽ cung cấp bước đột phá tiếp theo.

Parnas ngụ ý rằng thuật ngữ này được sử dụng cho sự quyến rũ, không phải cho nội dung ngữ nghĩa, khẳng định, "Nói tóm lại, lập trình tự động luôn là một uyển ngữ để lập trình với ngôn ngữ cấp cao hơn hiện tại dành cho lập trình viên."

Ông lập luận, về bản chất, trong hầu hết các trường hợp, đó là phương pháp giải pháp, không phải là vấn đề, mà đặc điểm kỹ thuật phải được đưa ra.

Về cơ bản, tôi cho rằng MDD chỉ là một uyển ngữ khác để lập trình với ngôn ngữ cấp cao hơn so với trước đây.

Điều đó không có nghĩa là lập trình bằng ngôn ngữ cấp cao hơn không thể giúp đỡ - thực tế nó thường có thể. Nhưng bản chất của vấn đề vẫn như cũ: cho dù công cụ hay ngôn ngữ bạn sử dụng tuyệt vời đến đâu, vào cuối ngày bạn cần suy nghĩ về tất cả các vấn đề và giải quyết vấn đề. Điều tốt nhất mà bất kỳ công cụ hay quy trình nào cũng có thể làm là loại bỏ "fuzz" để bạn có thể tập trung vào vấn đề quan trọng, như Brooks đã nói, " đặc tả , thiết kế và thử nghiệm cấu trúc khái niệm này ".

Bởi vì không phải tất cả các chương trình đều hướng đối tượng, điều mà tất cả các công cụ MDD dường như mong đợi. Bản thân UML dựa trên giả định của các đối tượng. Chắc chắn bạn có thể sử dụng sơ đồ tuần tự để mô hình hóa các chức năng, nhưng nhiều lần đó là vụng về.

Bởi vì có những lập trình viên như tôi, người nhận được nhiều tiến bộ và kết quả từ TDD hơn MDD.

Vì Mô hình hóa! = Lập trình.

Bởi vì chi phí / lợi ích quá cao ở phía chi phí và không đủ về phía lợi ích. Điều này có lẽ đã thay đổi kể từ lần cuối tôi nhìn vào MDD, sau đó bạn sẽ phải trả> $ 6000 / chỗ ngồi (USD) cho một công cụ có khả năng MDD vừa phải.

Bởi vì một mô hình mô tả đầy đủ một chức năng để tạo mã không còn hữu ích như một mô hình.

Bởi vì có những lập trình viên như tôi chỉ sử dụng các mô hình ở mức cao, và sau đó tìm ra các chi tiết bằng mã. Bạn thấy những điều khác biệt trong mã so với bạn làm trong phần mềm mô hình hóa.

Đó là một số lý do tại sao cá nhân tôi không làm MDD. Tôi đã được tiếp xúc với nó, nhưng không có gì có thể làm cho tôi một chuyển đổi. Có lẽ tôi quá già đi học. Có lẽ tôi quá mới học (dù đó là gì). Nó không phải là một công cụ mà tôi có thể tự trả tiền.

Microsoft / Apple / Google không đẩy nó :)

Những loại phát triển nào được phổ biến có liên quan nhiều đến các công cụ, người ủng hộ và truyền giáo. Rất khó để vượt qua điều gì đó mà không có người ủng hộ lớn (Ruby on rails có lẽ là ngoại lệ nhưng nó vẫn nhỏ so với Java / C # / Python)

Do một luật đơn giản ảnh hưởng đến tất cả các công cụ lập mô hình này, bạn biết, CASE, UML và như vậy:

Bắt giữa một lập trình viên và mã của anh ta rất tốn kém.

Nếu bạn làm như vậy, bạn cần xây dựng một trình biên dịch / trình thông dịch phù hợp, trình tạo mã dẫn đến luồng công việc khủng khiếp và phản hồi khủng khiếp cho lập trình viên (thông báo lỗi và như vậy).

Một trong những hiểu biết tuyệt vời của Thiết kế hướng miền là các Mô hình phải ở trong mã chứ không phải ở bên ngoài mã.

Cuối cùng, câu hỏi là: Tại sao mô hình của bạn không phù hợp với mã? Nếu bạn đang thực hiện phát triển nhúng và bị mắc kẹt với C hoặc cần tạo mã cho các nền tảng khác nhau, việc tạo mã có thể đáng giá. Đối với những người khác, một ngôn ngữ lập trình mạnh mẽ hơn và thiết kế mã tốt hơn thường tốt hơn so với thiết kế mã theo thứ gì đó ngoài mã.

• Có vẻ như một rắc rối khổng lồ cho rất ít lợi ích.
• Tôi dường như luôn lúng túng với các trường hợp cạnh và những điều kỳ lạ, những thứ ma thuật dường như không bao giờ thực sự hoạt động đúng.
• OO không phải là một viên đạn bạc; viết một phương pháp tạo phần mềm lên OO không làm cho nó bạc.

Nhưng tôi không thích các giải pháp enterprisey nói chung.

Tôi đã thảo luận và rất thích làm MDA, nhưng nhược điểm lớn nhất là hỗ trợ công cụ cho đến bây giờ. Tôi đang sử dụng một dẫn xuất của MDA mà tôi muốn gọi là "Đánh giá mô hình thời gian chạy", nhưng nhiều hơn về điều đó sau.

Những nhược điểm của MDA là, như tôi biết:

• Thiếu hỗ trợ tái cấu trúc: Hãy đoán tôi muốn mô hình hóa các thực thể của cơ sở dữ liệu của tôi với MDA (điển hình số 1). Nếu tôi có mô hình của mình, giả sử, một sơ đồ UML và tôi thay đổi nó, không có gì mã của tôi thay đổi với nó (ít nhất là các lớp được tạo) và thay vì vẫn còn một ứng dụng hoạt động với các thuộc tính được đặt tên tốt hơn, tôi nhận được một Rất nhiều lỗi tôi phải sửa bằng tay.
• Thiếu hỗ trợ gỡ lỗi: Thông thường các bản dịch từ mô hình sang mã được thực hiện bằng cách có sẵn một số ngôn ngữ chuyển đổi. Điều này thường không có vấn đề gì, nhưng khi chúng tôi gỡ lỗi, chúng tôi không nên lo lắng về mã mà chúng tôi tạo ra và trình gỡ lỗi nên bước vào mô hình chuyển đổi. Thay vào đó, nó bước vào mã được tạo và như chúng ta đều biết, các phép biến đổi sẽ trông tốt chứ không phải mã được tạo. Okey, chúng ta có thể in nó một cách đẹp mắt, nhưng trong một thế giới tối ưu, mã được tạo là một trình giả lập trình biên dịch và không bao giờ phải mở trong trình chỉnh sửa cho phiên gỡ lỗi (tôi có thể sống với nó và về mặt lý thuyết thì hơi lý thuyết, nhưng đó là một lý do chống lại MDA)
• Các mô hình được mã hóa rất dễ dàng: Trong các ví dụ khác, Mô hình có thể mô hình hóa một số khía cạnh miền và sau đó được biên dịch thành mã. Vâng, đó là MDA, nhưng hầu hết các mô hình MDA chỉ là các tệp cấu hình phức tạp, có thể dễ dàng xử lý khi chạy.
• Các phép biến đổi rất khó kiểm tra: Nếu bạn sử dụng các phép biến đổi trong một IDE chuyên dụng, chúng được thực hiện bởi "trình biên dịch" IDE. Nhưng các phép biến đổi phải được xem như là một phần của mã của ứng dụng và do đó cũng phải trải qua các yêu cầu kiểm tra và bảo hiểm mã của ứng dụng.

Điều tôi hiện đang thích là "Đánh giá mô hình thời gian chạy" (nếu ai đó biết một tên được chấp nhận cho điều này, xin hãy khai sáng cho tôi). Các thực thể của tôi được lưu trữ trong các lớp Java thông thường và mọi thứ tôi cần để "mô hình hóa" được tạo bởi các chú thích mà tôi đọc khi bắt đầu ứng dụng. Không có biến đổi cần thiết, thật khó để có được mô hình meta của tôi đúng.

Mọi thứ khác đều được thực hiện với các tệp thuộc tính hoặc XML cho dữ liệu phân cấp. Nếu bạn có một mô hình, nó luôn luôn được phân cấp, vì vậy không có gì bạn có thể mô hình mà bạn cũng không thể biểu thị bằng XML. Và nếu bạn cần một trình soạn thảo mô hình đặc biệt mà bạn có thể sẽ phải viết, bạn cũng có thể xây dựng một trình soạn thảo thậm chí hoạt động trong thời gian chạy của ứng dụng và làm cho ứng dụng có thể định cấu hình hơn mọi thứ bạn có thể tạo mô hình.

Tôi cảm thấy rằng hầu hết mọi người sử dụng No Silver Bullet của Fred Brooks để giải thích lý do tại sao mọi người không làm MDD lại thiếu điểm mà Brooks đưa ra. Chắc chắn, kết luận cuối cùng là sự phức tạp thực tế, nội tại trong việc phát triển phần mềm sẽ không bao giờ biến mất và vì vậy MDD sẽ không giải quyết điều này.

Nhưng một lý do mà Brooks thậm chí thảo luận về sự phức tạp nội tại này là so sánh nó với lượng thời gian lớn mà chúng ta thường dành để chiến đấu với các ngôn ngữ, thư viện và công cụ, tức là không giải quyết sự phức tạp nội tại của vấn đề chúng ta đang cố gắng giải quyết. Vì vậy, đây chính xác là nơi MDD tỏa sáng: cắt bỏ tất cả các fuzz và tạo ra một ngôn ngữ, mô hình hoặc chủ nghĩa hình thức khác để đối phó với sự phức tạp thực sự trong tay.

Vì vậy, từ quan điểm này, No Silver Bullet là một lý do tuyệt vời để đầu tư vào MDD. Đó là, nếu không phải là vấn đề mà tôi tin rằng cản trở việc áp dụng MDD: sự phát triển thực tế của môi trường theo mô hình cho phép bạn tập trung hoàn toàn vào sự phức tạp nội tại của vấn đề mà bạn đang cố gắng giải quyết khó khăn hơn nhiều so với chỉ giải quyết vấn đề bằng một ngôn ngữ có mục đích chung trực tiếp. Chủ yếu là vì công cụ MDD hiện tại là vô cùng phức tạp.

So sánh nó như thế này: viết chương trình bằng C dễ hơn nhiều so với viết trình biên dịch C. Thay vì chỉ giải quyết vấn đề và xử lý vấn đề bằng ngôn ngữ có mục đích chung, việc tạo môi trường MDD cho các nhà phát triển khác yêu cầu bạn phải viết một chương trình giải quyết tất cả các vấn đề liên quan đến hành trình có thể xảy ra trong không gian vấn đề. Điều đó khá khó khăn.

Theo hiểu biết của tôi, MDE và MDA không đáp ứng đủ nhu cầu của nhà phát triển bộ điều khiển nhúng. Các mô hình chắc chắn có thể được sử dụng để mô tả một hệ thống, nhưng tôi không nghĩ rằng nhà phát triển nhúng đã sẵn sàng tin tưởng vào mô hình để cung cấp mã nguồn tốt nhất hoặc thậm chí chính xác.

Có một số trình cắm cho Eclipse cho phép nhà phát triển sử dụng mô hình để tạo / cập nhật mã Java hoặc mã Java để tạo / cập nhật mô hình. Đây có vẻ như là một công cụ tiện dụng. Thật không may, tất cả sự phát triển của tôi được thực hiện trong ANSI / ISO C và không có trình cắm nào mà tôi biết, điều đó sẽ cho phép tôi làm điều tương tự.

Hơn nữa, làm thế nào một nhà phát triển có thể hướng dẫn mô hình triển khai mã dưới dạng HSM hướng sự kiện hoặc một số mẫu thiết kế khác, trên bất kỳ mẫu thiết kế nào khác (hoặc chống mẫu)? Nếu mã được cập nhật thủ công để sử dụng một mẫu thiết kế không xác định, mô hình có thể mô tả chính xác điều đó không?

Làm thế nào để bạn thực hiện các chức năng không phù hợp với một mô hình?

Câu trả lời ngắn gọn vì mô hình điều khiển thường liên quan đến việc tạo mã và mã rất mong manh; những gì chúng ta cần là loại bỏ mã và điều khiển mô hình chắc chắn là con đường để đi.

Một số người đã bác bỏ câu hỏi cho rằng không có búa vàng và việc phát triển phần mềm vốn đã phức tạp.

Tôi hoàn toàn đồng ý với họ rằng không có búa vàng nhưng tôi không nghĩ rằng mô hình được điều khiển là một nhiệm vụ của búa vàng hoặc đạn bạc!

Tôi muốn đi xa hơn với sự phức tạp; Có hai loại phức tạp mà tôi gọi là phức tạp hữu cơ hoặc tự nhiên, phức tạp vốn có của doanh nghiệp và các quy trình của nó nhưng chúng tôi cũng có sự phức tạp về nghi lễ.

Sự phức tạp len lỏi vào hướng dẫn hệ thống theo hướng dẫn, ngày qua ngày. Sự phức tạp về nghi lễ - sự phức tạp không cần thiết - xuất hiện chủ yếu từ việc xáo trộn mã kỹ thuật không kiểm soát được với mã định hướng kinh doanh, nhưng cũng do thiếu cấu trúc và tính đồng nhất trong hệ thống.

Ngày nay, toàn bộ sự phức tạp ám ảnh sự phát triển của hệ thống thông tin và gây ra sự thất bại và vòng eo là sự phức tạp về nghi lễ; sự phức tạp có thể được loại bỏ.

Sự phức tạp trong nghi lễ là sự lãng phí, lãng phí gây ra bởi mã, giá trị ít hơn, thay đổi bất lợi, mã bất biến; mã phải được giảm đến mức tối thiểu nghiêm ngặt của nó.

Làm thế nào để làm điều đó? Dễ thôi! Đừng viết nó, và đừng tạo ra nó, ngay từ đầu!

Cần thiết, mã kỹ thuật bất biến; mã được sử dụng để đọc / ghi, hiển thị, giao tiếp với nhau dữ liệu.

Nó giống như một hệ điều hành, bạn không viết lại nó cho mọi dự án bạn sử dụng. Vì vậy, những gì cần thiết là một công cụ kỹ thuật xử lý các khía cạnh bất biến của phần mềm được đưa ra một mô hình. Tôi gọi nó là một công cụ AaaS (Architecture as a Service).

Đối với mã không cần thiết, đó là mã không cần thiết vì vậy cũng có thể để nó không được mã hóa.

Điều đó cho chúng ta mã cần thiết, định hướng kinh doanh nên được viết, dữ liệu định hướng kinh doanh cần thiết phải được thiết kế và giao diện người dùng cần thiết và trải nghiệm cần được thiết kế và tưởng tượng.

Bằng cách loại bỏ mã dễ vỡ, chúng ta có thể nắm lấy Kiến trúc như một Dịch vụ một mô hình mới để phát triển phần mềm dựa nhiều vào mô hình hóa và thiết kế hơn là mã.

Tôi tin rằng có một số lý do nhưng một lý do chắc chắn là MDD không có trong chương trình giảng dạy của các trường đại học. Điển hình nhất là một khóa học dạy mô hình hóa và ở đó các mô hình ở dạng phác thảo (không kiểm tra, tạo mã, gỡ lỗi ở cấp độ mô hình). Khóa học mô hình hóa này của người Viking thường cũng giới thiệu UML và sinh viên rất bối rối tại sao phải học một ký hiệu lớn và phức tạp như vậy khi giá trị của các mô hình được tạo ra thấp.

Tương phản điều này với lĩnh vực kỹ thuật khác như các nhà phát triển phần cứng nhúng hoặc kỹ sư điều khiển nơi sinh viên có được trải nghiệm khá khác biệt. Với các công cụ như Simulink hoặc Labview, sinh viên có thể vẽ một mô hình và sau đó nó tạo ra mã cho bạn hoặc ít nhất bạn có thể chạy nó trong mô phỏng.

Trước đây các trường đại học dạy trình biên dịch và trình phân tích cú pháp, nhưng bây giờ họ nên dạy cách tạo máy phát điện, triển khai DSL, v.v.

Mô hình hướng phát triển là không có ý nghĩa bởi vì đây là mô hình từ trên xuống để tiếp cận mã. Không thể tạo ứng dụng chạy hoàn toàn chỉ từ một mô hình và do đó MDD là vô dụng !!

Những gì tôi làm là chỉ sử dụng UML ở mức độ trừu tượng cao hơn để tạo bộ xương cho ứng dụng của tôi. Ý tôi là tạo các Gói, các lớp, v.v ... sau đó bắt đầu ngay lập tức để viết mã bằng ngôn ngữ Java.

Tôi thấy rằng đồng bộ hóa trực tiếp với các công cụ như Togethersoft, Omondo thực sự hữu ích khi tôi lần đầu tiên bắt đầu lập mô hình vào năm 2004. Một giai đoạn mới đã được Omondo giới thiệu gần đây là một loại ánh xạ giữa Java, mô hình và ID cơ sở dữ liệu. Thực sự mạnh mẽ và nó hoạt động tốt trong các dự án của tôi.

Các sơ đồ UML của tôi giúp tôi tăng tốc dự án của mình và không còn vô dụng nữa :-)

MDD thêm một bước nữa vào quá trình phát triển, đó là một nhược điểm trong các tình huống không có mô hình tốt và giải pháp một phần không thể đoán trước hoặc gần như bị phá vỡ để thị trường có thể giành được nhiều viên bi nhất.

Nó đã được chén thánh để có các mô hình quy trình kinh doanh thực thi. Về lý thuyết bạn sẽ không cần lập trình viên cho điều đó cả. Thực tế cho thấy, với MDE, việc mô hình thực tế hoạt động cũng phức tạp như viết mã.

Tôi muốn nói với nhà phát triển có kinh nghiệm, việc điền vào các lớp được tạo từ UML sẽ dễ dàng hơn nhiều so với việc thực hiện ví dụ như ExecutableUML. Mặt khác, đối với ExecutableUML, bạn cần một lượng kiến ​​thức khoa học máy tính đáng kể, vì vậy bạn không thể tin tưởng vào người quản lý doanh nghiệp tự mình tạo ra nó. Về lý thuyết, anh ta chỉ kết hợp các khối (lớp) sẵn sàng, nhưng thực sự "keo" là nguyên nhân gây ra vấn đề.

Ngoài ra, tính hữu dụng của MDE chỉ giới hạn ở các hệ thống có nhiều tái sử dụng thành phần.

MBSE - Kỹ thuật phần mềm dựa trên mô hình là thuật ngữ thích hợp hơn.

Đặt vấn đề của các công cụ khác nhau trong các giải pháp điểm hiệu quả, MBSE yêu cầu một quy trình làm việc dự án khác nhau. DSML (ngôn ngữ mô hình hóa cụ thể miền) cần ở mức độ trừu tượng cần thiết để truyền đạt hiệu quả các yêu cầu để xem xét với các bên liên quan. Sau đó, bạn cần chuyển đổi mô hình thông qua các mức độ tinh chỉnh ngày càng tăng để cuối cùng tạo mã.

Khi bạn có DSML và các quy trình chuyển đổi / tạo được thực hiện đầy đủ và chính xác thì việc tạo các tạo phẩm có chi phí rất thấp. Nhưng cho đến khi bạn đạt đến giai đoạn gỡ lỗi đó, nó rất đau.

Hầu hết các câu chuyện thành công cho MDD là trong lĩnh vực Kỹ thuật dòng sản phẩm (PLE), nơi một chuỗi các sản phẩm tương tự được tạo ra bằng cách sử dụng công cụ được thiết lập. Tất nhiên, nhiều trình tạo mã Java là các phiên bản MDD thực sự đơn giản hóa. Một số XML trong và tạo mã ra.

Bạn đã viết:

Tôi cũng biết có rất nhiều vấn đề ... các dự án không phù hợp với sự phát triển theo mô hình (không đủ sự lặp lại)

Nếu mã của bạn lặp đi lặp lại, thì bạn đã chọn ngôn ngữ lập trình kém hoặc bạn đang sử dụng nó không tốt. Với các ngôn ngữ tốt hơn, không cần phải lặp lại. Hãy xem xét thư viện Ruby Active Record. Bảng cơ sở dữ liệu được tạo bằng cách viết di chuyển. Không cần lặp lại định nghĩa lược đồ ở bất kỳ nơi nào khác. Bạn không phải xác định một lớp có các thành viên dữ liệu tương ứng với các cột của bảng. Một dòng mã duy nhất kết nối một lớp với một bảng.

Tôi xem sự phát triển theo mô hình là một công việc phức tạp và không hiệu quả đối với các ngôn ngữ lập trình yếu.