Bạn có đang thực hiện MDA (Kiến trúc định hướng mô hình) ngay bây giờ không? Nếu vậy, bạn sử dụng công cụ nào và công cụ này hoạt động như thế nào?

Question

Kiến trúc điều khiển mô hình là ý tưởng bạn tạo ra các mô hình thể hiện vấn đề bạn cần giải quyết theo cách không có bất kỳ công nghệ triển khai nào (và ít nhất là hầu hết) và sau đó bạn tạo triển khai cho một hoặc nhiều nền tảng cụ thể. Yêu cầu bồi thường là làm việc ở mức trừu tượng cao hơn là mạnh hơn và hiệu quả hơn nhiều. Ngoài ra, các mô hình của bạn còn sống động hơn công nghệ (do đó bạn vẫn có thứ gì đó khi ngôn ngữ/nền tảng đầu tiên của bạn trở nên lỗi thời mà bạn có thể sử dụng cho giải pháp thế hệ tiếp theo của mình). Một lợi ích khác được tuyên bố chủ yếu là phần lớn các bản mẫu và "công việc grunt" có thể được tạo ra. Khi máy tính hiểu được ngữ nghĩa của tình huống của bạn, nó có thể giúp bạn nhiều hơn.

Một số tuyên bố phương pháp này hiệu quả hơn gấp 10 lần và rằng đó là cách tất cả chúng ta sẽ xây dựng phần mềm trong 10 năm.

Tuy nhiên, đây chỉ là lý thuyết. Tôi tự hỏi kết quả là gì khi cao su gặp đường. Ngoài ra, phiên bản "chính thức" của MDA là từ OMG và có vẻ rất nặng. Nó dựa chủ yếu vào UML, có thể được coi là tốt hay xấu tùy thuộc vào người bạn yêu cầu (tôi nghiêng về phía "xấu").

Nhưng, bất chấp những lo ngại đó, thật khó để tranh luận với ý tưởng làm việc ở mức trừu tượng cao hơn và "dạy" máy tính để hiểu ngữ nghĩa của vấn đề và giải pháp của bạn. Hãy tưởng tượng một loạt các mô hình ER chỉ đơn giản là thể hiện sự thật, và sau đó hãy tưởng tượng sử dụng chúng để tạo ra một phần đáng kể giải pháp của bạn, đầu tiên trong một bộ công nghệ và sau đó lại trong một bộ công nghệ khác.

Vì vậy, Tôi rất muốn nghe từ những người thực sự đang thực hiện MDA ngay bây giờ ("chính thức" hay không). Bạn đang sử dụng công cụ nào? Làm thế nào nó làm việc ra? Bạn có thể nắm bắt được bao nhiêu lời hứa lý thuyết? Bạn có thấy mức tăng hiệu quả 10X thực sự không?

Answer 1

Tôi đã thử một lần. Khoảng chừng nửa chừng dự án, tôi nhận ra rằng các mô hình của tôi đã lạc hậu từ mã của tôi và quá phức tạp đến mức giữ cho chúng được cập nhật là cấm và làm chậm tôi.

Vấn đề là phần mềm có đầy đủ các trường hợp cạnh. Mô hình tuyệt vời khi chụp ảnh lớn hơn nhưng khi bạn bắt đầu thực sự mã hóa việc triển khai, bạn tiếp tục tìm tất cả các trường hợp cạnh đó và trước khi quá lâu bạn nhận thấy rằng mô hình quá chi tiết và bạn phải lựa chọn giữa việc duy trì mô hình hoặc nhận một số mã được viết. Có lẽ thế hệ boilerplate là một lợi ích để bắt đầu nhưng sau đó lợi ích nhanh chóng biến mất và tôi thấy rằng tôi đã giảm đáng kể năng suất. Các mô hình cuối cùng biến mất khỏi dự án đó.

Answer 2

Việc thiếu phản hồi cho câu hỏi này có phần đáng ngại ... có thể tôi sẽ để trường Dijkstra điền vào.

... Bởi vì máy tính xuất hiện trong một thập kỷ khi niềm tin vào sự tiến bộ và lành của khoa học và công nghệ là hầu như không giới hạn, nó có thể là khôn ngoan để nhớ lại rằng, theo quan điểm các mục tiêu ban đầu của nó, của nhân loại nỗ lực khoa học trên, nói rằng, năm thế kỷ qua đã là một sự thất bại ngoạn mục .

Như tất cả các bạn đã nhớ, mục tiêu đầu tiên và là phát triển của Elixir sẽ cung cấp cho một mà đã uống nó Thanh niên Vĩnh cửu. Nhưng kể từ khi không có nhiều điểm trong sự nghèo đói vĩnh hằng , thế giới khoa học nhanh chóng bắt tay vào dự án thứ hai của nó, tức là. Hòn đá của Nhà triết học sẽ cho phép bạn kiếm được nhiều Vàng như bạn cần thiết.

...

Nhiệm vụ cho lý tưởng lập trình ngôn ngữ và lý tưởng người-máy giao diện đó sẽ làm cho cuộc khủng hoảng phần mềm tan chảy như tuyết dưới ánh mặt trời đã -Và vẫn có!- tất cả các đặc điểm của việc tìm kiếm Elixir và Đá. Đây tìm kiếm nhận hỗ trợ mạnh mẽ từ hai bên, trước hết là từ thực tế là các làm phép lạ là rất ít mà bạn có thể mong đợi từ máy tính, và thứ hai từ sự ủng hộ chính trị và tài chính từ một xã hội mà đã luôn luôn yêu cầu cho Elixir và Đá ngay từ đầu.

Hai luồng chính có thể là phân biệt, nhiệm vụ cho Stone và nhiệm vụ cho Elixir.

Nhiệm vụ cho Stone dựa trên giả định rằng "công cụ lập trình " của chúng tôi quá yếu. Một ví dụ là niềm tin rằng lập trình hiện tại ngôn ngữ thiếu "tính năng" mà chúng tôi cần. PL/I là một trong những loại đá ngoạn mục hơn sẽ được sản xuất. Tôi vẫn còn nhớ quảng cáo theo số Datamation, 1968, trong đó mỉm cười Susie Mayer thông báo đầy đủ màu rằng cô ấy đã giải quyết tất cả các vấn đề lập trình của mình bằng cách chuyển sang PL/I. Nó chỉ là quá dễ thấy rằng, một vài năm sau, người nghèo Susie Mayer sẽ không còn mỉm cười nữa. Không cần để nói rằng nhiệm vụ được tiếp tục và vào đúng hạn là thời gian một hòn đá kế tiếp là được sản xuất dưới dạng Ada (phía sau Bức màn sắt được gọi là là PL/II). Ngay cả các tiểu học nhất chiêm tinh học cho người mới bắt đầu đủ để dự đoán rằng Ada sẽ không phải là cuối cùng đá thuộc loại này.

...

Một loạt đá theo hình thức của "công cụ lập trình" được sản xuất dưới ngọn cờ của "phần mềm kỹ thuật", trong đó, khi thời gian trôi qua, đã tìm cách thay thế hữu trí tuệ kỷ luật theo kỷ luật quản lý tới mức độ hiện đã được chấp nhận là điều lệ của chương trình "Cách lập trình nếu bạn không thể".

Answer 3

Tôi đang nghiên cứu độc lập trong khu vực Phát triển phần mềm theo mô hình từ năm 1999. Cuối cùng tôi đã phát triển một phương pháp mô hình hóa chung vào năm 2006 mà tôi gắn nhãn ABSE (Atom-Based Software Engineering).

Vì vậy, ABSE xây dựng lên trên hai khía cạnh cơ bản:

• Lập trình là về vấn đề phân hủy
• Tất cả mọi thứ có thể được biểu diễn trên một cây

Một số ABSE tính năng:

• Nó có thể hỗ trợ tất cả các hình thức kỹ thuật phần mềm khác, từ tradi tional phương pháp định hướng tệp dựa trên Phát triển dựa trên thành phần, Lập trình hướng đến khía cạnh, Mô hình hóa miền cụ thể, Dòng sản phẩm phần mềm và Nhà máy phần mềm.

• Nó là đủ chung để được áp dụng cho phần mềm doanh nghiệp, nhúng, trò chơi, điện tử hàng không, internet, bất kỳ tên miền nào trên thực tế.

• Bạn không cần phải là nhà khoa học tên lửa để sử dụng nếu có hiệu quả. ABSE có thể truy cập được tới "nhà phát triển sinh tử". Không có sự phức tạp như trong chuỗi công cụ oAW/MDA/XMI/GMF/etc.

• Siêu mô hình meta được thiết kế để hỗ trợ tạo mã 100% từ mô hình. Không có chuyến đi khứ hồi cần thiết. Hỗn hợp mã tùy chỉnh/được tạo được hỗ trợ trực tiếp bởi metamodel.

• Mô hình có thể được thao tác đồng thời. Có thể áp dụng quy trình làm việc và kiểm soát phiên bản (cần hỗ trợ công cụ).

Nghe có vẻ như đó là ở phía bên utopic, nhưng thực sự tôi rời khỏi giai đoạn nghiên cứu và bây giờ tôi đang trong giai đoạn thực hiện của một IDE mà đặt tất cả ở trên vào thực tế. Tôi nghĩ rằng tôi sẽ có một nguyên mẫu cơ bản sẵn sàng trong một vài tuần (khoảng cuối tháng tư). IDE (có tên AtomWeaver) đang được xây dựng thông qua ABSE, do đó AtomWeaver sẽ là chứng minh đầu tiên về phương pháp ABSE.

Vì vậy, đây không phải là MDA (may mắn!), Nhưng ít nhất là một cách tiếp cận rất dễ quản lý. Với tư cách là người phát minh ra ABSE, tôi rất vui mừng về nó, nhưng tôi chắc chắn Phát triển phần mềm theo mô hình sẽ được tăng cường trong năm 2009!

Stay tuned ...

Answer 4

Model-Driven Phát triển phần mềm vẫn là một khu vực thích hợp nhưng có những trường hợp nghiên cứu được công bố và một cơ thể đang phát triển của văn học khác cho thấy sự thành công trên phương pháp tay-mã.

MDA của OMG chỉ là một cách tiếp cận, những người khác đang thể hiện thành công bằng cách sử dụng Ngôn ngữ cụ thể theo miền (không sử dụng UML để lập mô hình).

Điều quan trọng là tạo mã từ các mô hình và cập nhật trình tạo của bạn nếu nó không tạo ra thứ bạn muốn - không sửa đổi mã của bạn. Công cụ chuyên gia để giúp bạn thực hiện điều này đã tồn tại trong nhiều năm nhưng quan tâm đến cách tiếp cận này đã phát triển trong 5 năm qua do sự di chuyển của Microsoft vào lĩnh vực này và thông qua các dự án mã nguồn mở như openArchitectureWare trong thế giới Eclipse.

Tôi chạy một vài trang web: www.modeldrivensoftware.net và www.codegeneration.net nơi bạn có thể nhận được nhiều cuộc thảo luận, phỏng vấn, bài viết và tùy chọn công cụ hơn về các chủ đề này.