Luận văn: Sinh mã tự động trong phát triển phần mềm hướng mô hình - ĐH Công nghệ

Luận văn thạc sĩ về sinh mã tự động trong phát triển phần mềm hướng mô hình. Nghiên cứu các kỹ thuật và ứng dụng để tăng hiệu quả lập trình.

Chuyên ngành

Công Nghệ Thông Tin

Người đăng

Ẩn danh

Thể loại

Luận Văn Thạc Sĩ

2014

113
1
0

Phí lưu trữ

35 Point

Mục lục chi tiết

LỜI CAM ĐOAN

LỜI CẢM ƠN

DANH MỤC CÁC KÝ HIỆU CÁC CHỮ VIẾT TẮT

DANH MỤC CÁC HÌNH ẢNH VÀ ĐỒ THỊ

DANH MỤC CÁC BẢNG BIỂU

MỞ ĐẦU

1. CHƯƠNG 1: TỔNG QUAN CÔNG NGHỆ PHÁT TRIỂN HƯỚNG MÔ HÌNH

1.1. Ứng dụng MDA trong quy trình phát triển phần mềm

1.1.1. Phát triển phần mềm theo phương pháp truyền thống

1.1.2. Phát triển phần mềm theo phương pháp hướng mô hình (MDD)

1.2. Những thuận lợi của kiến trúc hướng mô hình (MDA)

1.2.1. Chất lượng sản phẩm

1.2.2. Khả năng tương thích

1.2.3. Khả năng tương tác

1.2.4. Bảo trì và Tư liệu

1.3. Cơ bản về MDA

1.3.1. Mô hình (model) là gì?

1.3.2. Chuyển đổi mô hình

1.3.3. Các đặc điểm mong muốn của sự chuyển đổi

1.3.3.1. Khả năng truy tìm nguồn gốc
1.3.3.2. Tính nhất quán gia tăng
1.3.3.3. Tính hai chiều

1.3.4. Mô hình bốn lớp của MDA

1.3.5. Ví dụ về MOF

1.4. Các tiêu chuẩn của OMG được sử dụng với MDA

1.5. Tổng kết chương

2. KHẢO SÁT KHẢ NĂNG SINH MÃ TỰ ĐỘNG TRONG MDD

2.1. Các bộ sinh mã hướng mô hình

2.1.1. Sử dụng Khuôn mẫu và Bộ lọc (Template and Filtering)

2.1.2. Sử dụng Khuôn mẫu và Meta-Model (Template and Meta-Model)

2.1.3. Sử dụng Bộ sinh dựa trên API (API-based Generator)

2.1.4. Sử dụng Sinh mã nội tuyến (Inline Code Generation)

2.2. Công cụ chuyển đổi mô hình

2.2.1. Ngôn ngữ mục đích chung (General-Purpose Languages)

2.2.1.1. Ngôn ngữ đánh máy (Strongly Typed Languages)
2.2.1.2. Ngôn ngữ kịch bản (Loosely Typed Languages - Scripting)

2.2.2. Ngôn ngữ phụ thuộc miền (Domain-Specific Languages)

2.2.3. Ngôn ngữ chuyển đổi mô hình sang văn bản

2.2.3.1. MOF Model to Text (MOFM2T)

2.3. Những lợi ích của việc sinh mã hướng mô hình

2.3.1. Sự nhất quán

2.3.2. Sự linh hoạt

2.3.3. Tính di động

2.3.4. Phân tách các khía cạnh

2.3.5. Tốc độ phát triển

2.3.6. Tăng thời gian phân bổ cho các pha chính

2.4. Rủi ro từ việc áp dụng sinh mã

2.4.1. Phần mềm không phù hợp cho việc sinh mã

2.4.2. Chất lượng của phần mềm sinh mã kém

2.5. Tổng kết chương

3. CÔNG NGHỆ WEB HƯỚNG MÔ HÌNH

3.1. Phương pháp tiếp cận

3.1.1. Phân tách các khía cạnh

3.1.2. Môi trường chuyển đổi

3.2. Công nghệ Web hướng mô hình UWE

3.2.1. Tổng quan về UWE

3.2.2. Các phương pháp khác trong MDWE so sánh với UWE

3.2.2.1. Object-Oriented Hypermedia (OO-H)
3.2.2.2. Object-Oriented Web Solution (OOWS)

3.3. Tự động sinh mã trong UWE4JSF

3.3.1. Tổng quan về UWE4JSF

3.3.2. Chuyển đổi mô hình và cơ chế thẩm định mô hình trong UWE4JSF

3.3.2.1. Chuyển đổi mô hình UML2UWE
3.3.2.2. Cơ chế thẩm định của UWE4JSF

3.3.3. Chuyển đổi mô hình sang mô hình UWE2JSF

3.3.4. UWE4JSF Meta-model

3.3.5. Chuyển đổi mô hình sang văn bản trong UWE4JSF

3.4. Cấu trúc của ứng dụng UWE4JSF

3.5. Tổng kết chương

4. THỰC NGHIỆM VỚI UWE4JSF

4.1. Đặc tả yêu cầu

4.1.1. Biểu đồ ca sử dụng (Use Case Diagram)

4.1.2. Biểu đồ hoạt động (Activity Diagram)

4.2. Thiết kế mô hình

4.2.1. Mô hình nội dung (Content)

4.2.2. Mô hình điều hướng (Navigation)

4.2.3. Mô hình xử lý (Process)

4.2.4. Mô hình biểu diễn (Presentation)

4.2.4.1. Giao diện tổng thể
4.2.4.2. Giao diện nhập liệu
4.2.4.3. Concrete Presentation Model

4.3. Thực hiện sinh mã

4.4. Đánh giá kết quả

4.5. Tổng kết chương

TÀI LIỆU THAM KHẢO

Các plug-in của công cụ UWE4JSF

Phụ Lục B. Thực hành với MagicUWE

Thực hành chuyển đổi với Eclipse IDE

Tóm tắt

I. Tổng Quan Về Sinh Mã Tự Động Trong Phát Triển MDD

Khoa học máy tính liên tục nâng cao mức độ trừu tượng của ngôn ngữ máy tính để viết các chương trình, từ mã nhị phân đến hợp ngữ, ngôn ngữ thủ tục, hướng đối tượng và mô hình hóa. Mục tiêu là phát triển các cơ chế diễn tả hơn, cho phép lập trình viên phát triển mã nguồn tổ chức tốt, linh hoạt, mở rộng, mạnh mẽ và ít tốn công sức. Nghiên cứu về sinh mã là thiết yếu để xây dựng công cụ tạo mã, tài liệu và mô hình liên quan. Như đã trình bày trong Chương 1 về MDA, bước cuối cùng là tạo mã thực thi, các file cấu hình, mô tả thành phần, file triển khai, và các kịch bản xây dựng. Phạm vi và hành vi thực thi ứng dụng được mô tả trong PIMPSM càng hoàn thiện, các yếu tố được tạo ra càng hoàn thiện. Với sự tự động tối thiểu, công việc phát triển cũng đơn giản đi nhiều. Việc sử dụng kiến trúc nhất quán cho quản lý khía cạnh độc lập nền và phụ thuộc nền của ứng dụng cũng là nguyên do cho sự tự động sinh mã được nghiên cứu. Hình 2.12 thể hiện sự trừu tượng hóa tăng dần của ngôn ngữ máy tính.

1.1. Tầm Quan Trọng Của Tự Động Sinh Mã Trong MDD

Trong phát triển phần mềm, sinh mã tự động đóng vai trò then chốt trong việc tăng tốc độ và giảm thiểu sai sót. Thay vì viết mã thủ công, hệ thống tự động tạo ra mã từ các mô hình hoặc đặc tả. Điều này giúp tiết kiệm thời gian, giảm chi phí và nâng cao chất lượng phần mềm. Sinh mã còn giúp đơn giản hóa quy trình phát triển, cho phép các nhà phát triển tập trung vào các khía cạnh quan trọng khác như thiết kế và kiến trúc. Các công cụ sinh mã hiện đại thường tích hợp các kỹ thuật tối ưu hóa, giúp tạo ra mã hiệu quả và dễ bảo trì.

1.2. Các Yếu Tố Ảnh Hưởng Đến Hiệu Quả Sinh Mã Tự Động

Hiệu quả của sinh mã tự động phụ thuộc vào nhiều yếu tố, bao gồm chất lượng của các mô hình đầu vào, khả năng tùy biến của công cụ sinh mã, và mức độ tích hợp với các công cụ phát triển khác. Các mô hình cần được xây dựng chính xác và đầy đủ để đảm bảo mã được tạo ra đáp ứng các yêu cầu. Công cụ sinh mã cần cung cấp khả năng tùy biến linh hoạt để đáp ứng các nhu cầu cụ thể của dự án. Cuối cùng, việc tích hợp với các công cụ phát triển khác như IDE, hệ thống quản lý phiên bản và công cụ kiểm thử giúp tạo ra một quy trình phát triển liền mạch.

II. Phương Pháp Sinh Mã Hướng Mô Hình Phổ Biến Trong MDA

Các bộ sinh mã thay đổi từ các đoạn kịch bản tuỳ biến ngắn gọn, hoặc các chương trình chạy ở chế độ console với đầu vào tối thiểu cung cấp đầu ra tiền định nghĩa, cho tới các công cụ trực quan có thể sinh toàn bộ hệ thống từ đầu vào là các định nghĩa mô hình phức tạp hơn. Mục này sẽ đề cập cụ thể hơn đến việc sinh mã hướng mô hình tuân theo kiến trúc MDA. Đối với MDA việc sinh mã tự động hướng mô hình được mô tả ở Hình 2.13: Chuyển đổi mô hình sang mã nguồn theo MDA Trong đó mô hình nguồn (Source Model) được viết bởi nhiều ngôn ngữ mô hình hoá khác nhau. Đích (Target) là các đoạn mã phù hợp với cú pháp của các ngôn ngữ nền tảng như C/C++, Java, vân vân. Đích cũng được xem như là mã nguồn hay chương trình (Code/Program).

2.1. Khuôn Mẫu và Bộ Lọc Phương Pháp Sinh Mã Đơn Giản

Phương pháp này mô tả cách đơn giản nhất để sinh mã. Thông thường, mã được tạo bằng cách áp dụng khuôn mẫu cho đặc tả mô hình văn bản (thường là XML/XMI), và sau khi lọc một vài phần của đặc tả. Một phần của mã nguồn cũng được nhúng trong khuôn mẫu. Ví dụ: Mã được sinh ra bằng Java và XML. Khuôn mẫu (template) được viết bằng XSTL. Mã Java được nhúng trực tiếp vào khuôn mẫu cùng với các Bộ lọc. Các bộ lọc này sẽ đọc giá trị từ mô hình nguồn để điền vào khuôn mẫu.

2.2. Khuôn Mẫu và Meta Model Mở Rộng Sinh Mã Linh Hoạt

Phương pháp này là một sự mở rộng của phương pháp "Template and Filtering". Thay vì áp dụng khuôn mẫu trực tiếp vào mô hình, thì việc đầu tiên là khởi tạo một meta-model từ đặc tả rồi mới áp dụng khuôn mẫu vào. Khuôn mẫu được mô tả trong phạm vi của meta-model. Meta-model có thể được mở rộng để bao gồm các khía cạnh miền hay kiến trúc cụ thể. Meta-model đóng vai trò quan trọng trong việc mô tả cấu trúc và ngữ nghĩa của mô hình, giúp quá trình sinh mã trở nên chính xác và hiệu quả hơn.

2.3. Bộ Sinh Dựa Trên API Kiểm Soát Mã Nguồn Nâng Cao

Client Program sẽ gọi APIAPI này thông thường dựa vào meta-model hay cú pháp của ngôn ngữ đích (Grammar) để sinh mã. Phương pháp này cho phép kiểm soát chặt chẽ hơn quá trình sinh mã, đảm bảo mã nguồn đáp ứng các tiêu chuẩn và yêu cầu cụ thể. Các API cung cấp các hàm và lớp để tạo, sửa đổi và quản lý mã nguồn. Điều này giúp các nhà phát triển tùy biến và mở rộng khả năng sinh mã một cách dễ dàng.

III. Công Cụ Chuyển Đổi Mô Hình Hàng Đầu Cho Sinh Mã MDA

Trên thị trường hiện nay có rất nhiều công cụ chuyển đổi mô hình, mỗi công cụ đều có những ưu việt riêng. Tuy nhiên trong phạm vi luận văn này, tác giả chỉ đề cập đến một số công cụ phổ biến sau. 3.1 EMF (Eclipse Modeling Framework) Khung mô hình hoá Eclipse (EMF) là nền tảng mô hình hoá tinh vi đằng sau trình phát triển Eclipse. Mặc dù EMF chỉ được phát hành như một dự án con của Eclipse vào năm 2003, nhưng nó có một di sản lâu năm từ trình quản lý meta-data hướng mô hình của công cụ Visual Age IDE của IBM. EMF phần lớn là tương thích MDA với chỉ duy nhất sai lệch nhỏ từ một vài tiêu chuẩn.

3.1.1. Eclipse Modeling Framework EMF Tối Ưu Cho MDD

Eclipse Modeling Framework (EMF) là một framework mạnh mẽ cho phép xây dựng các công cụ và ứng dụng dựa trên mô hình. Với khả năng hỗ trợ các chuẩn mô hình hóa phổ biến như MOFUML, EMF là một lựa chọn tuyệt vời cho việc phát triển các ứng dụng MDD. Nó cung cấp một loạt các tính năng, bao gồm tạo mô hình, chuyển đổi mô hình và sinh mã, giúp đơn giản hóa quy trình phát triển và tăng năng suất.

3.1.2. MDR Metadata Repository Lưu Trữ Meta Data Tuân Thủ Chuẩn

MDR là dự án mã nguồn mở được thành lập bởi Netbeans.org. MDR rất ổn định, và chỉ có những thay đổi nhỏ đi cùng với các bản phát hành mới của Netbeans. MDR là bộ lưu trữ meta-data tuân thủ các chuẩn MOF, XMIJMI. Nó cung cấp truy cập tức thời tới meta-data qua một tập các API phụ thuộc meta-model được tạo hoặc API độc lập meta-model.

3.1.3. AndroMDA Nền Tảng Mã Nguồn Mở Tương Thích MDA

AndroMDA là nền tảng mã nguồn mở tương thích MDA, nó có cơ chế cho phép các nền tảng và các thành phần hỗ trợ có thể hoán đổi trong và ngoài bất cứ lúc nào. Nó được khai thác nhiều bởi các dự án nguồn mở hiện tại cho cả mục đích xây dựng dịch vụ phụ thuộc nền và dịch vụ nền tảng chung. Với AndroMDA, lập trình viên có thể mở rộng ngôn ngữ mô hình hoá hiện tại qua các tiện ích như “metafacades”.

IV. Khuôn Mẫu và Ngôn Ngữ Chuyển Đổi Trong Sinh Mã Tự Động

Ngôn ngữ được sử dụng trong các khuôn mẫu là đặc trưng quan trọng của bộ tạo mã. Một ngôn ngữ thích hợp cho thành phần của các khuôn mẫu nên ngắn gọn, mạnh mẽ, và sát với miền mà bộ tạo mã hướng tới. Trong phần này, các dạng ngôn ngữ khác nhau được mô tả, cũng như những thuận lợi và bất lợi của chúng được đề cập đến. 4.1 Ngôn ngữ mục đích chung (General-Purpose Languages)

4.1.1. Ngôn Ngữ Mục Đích Chung So Với Ngôn Ngữ Phụ Thuộc Miền

Ngôn ngữ mục đích chung cho phép lập trình viên có những đặc điểm tính toán không giới hạn, nhưng nó cũng liên quan đến nguy cơ xuất hiện các lỗi logic trong khuôn mẫu, khi mà cú pháp của chúng phức tạp hơn. Ngược lại, Ngôn ngữ phụ thuộc miền gồm các đặc điểm cho sự lặp đi lặp lại và không cung cấp các tính năng cao hơn như tính toán. Lợi thế của những ngôn ngữ này là dễ học, khi chúng thường gồm một số ít khái niệm và sự diễn tả liên quan tới miền ứng dụng.

4.1.2. Xpand Ngôn Ngữ Chuyển Đổi Mạnh Mẽ Trong OpenArchitectureWare

Ngôn ngữ Xpand được phát triển như là một phần của dự án openArchitecture- Ware (oAW) dùng cho việc chuyển đổi gồm cả từ mô hình sang mô hình và mô hình sang văn bản. Xpand là một dạng của ngôn ngữ phụ thuộc miền. Các khuôn mẫu (được viết bằng ngôn ngữ này) được sử dụng bởi bộ sinh mã mà là một phần của luồng phát triển của nền tảng oAW. Xpand là độc lập với các dạng mô hình.

4.1.3. JET Java Emitter Templates Sinh Mã Dễ Dàng Với JSP

JET là công cụ mã nguồn mở . Nó cung cấp một khung công tác (framework) và tiện ích cho việc sinh mã. Các file khuôn mẫu dạng JSP được sử dụng và qua đó nó giúp lập trình viên mà đã thân thuộc với công nghệ JSP dễ dàng học được. Mặc định JET yêu cầu file XML là đầu vào, file XML này không nhất thiết là một dạng XML cụ thể nào, và không liên quan đến mô hình hoá phần mềm.

V. Lợi Ích và Rủi Ro Khi Triển Khai Sinh Mã Hướng Mô Hình

Việc áp dụng sinh mã hướng mô hình mang lại nhiều lợi ích, nhưng cũng tiềm ẩn một số rủi ro. Cần cân nhắc kỹ lưỡng các yếu tố này để đảm bảo việc triển khai thành công. Lợi ích lớn nhất là tăng năng suất và giảm chi phí. Sinh mã tự động giúp giảm thời gian và công sức cần thiết để phát triển phần mềm, đồng thời giảm thiểu sai sót do lập trình thủ công.

5.1. Lợi Ích Vượt Trội Của Sinh Mã Tự Động Trong MDD

Những lợi ích lớn nhất của sinh mã hướng mô hình là sự nhất quán, sự linh hoạt, tính di động, phân tách các khía cạnh, tốc độ phát triển và tăng thời gian phân bổ cho các pha chính. Tốc độ phát triển theo số liệu năm 2009 của MetaCase [18] được thể hiện trong hình 2.25.

5.2. Rủi Ro Tiềm Ẩn Khi Ứng Dụng Sinh Mã Tự Động

Mặc dù mang lại nhiều lợi ích, sinh mã hướng mô hình cũng tiềm ẩn một số rủi ro. Phần mềm không phù hợp cho việc sinh mã, chất lượng của phần mềm sinh mã kém. Cần đánh giá kỹ lưỡng các yếu tố này để đảm bảo việc triển khai sinh mã tự động thành công. Đảm bảo rằng phần mềm được chọn phù hợp với phương pháp tiếp cận này, và công cụ sinh mã được sử dụng tạo ra mã chất lượng cao.

23/09/2025

Trích đoạn nội dung tài liệu

Phần Mở Đầu, khi các nhà phát triển đang đối mặt với nhiều vấn đề về sự phát triển nhanh chóng và ngày càng phức tạp của các nền tảng công nghệ mới. Do đó, họ phải dành nhiều công sức và thời gian để tuỳ biến ứng dụng (thường theo cách thủ công là sửa mã nguồn) sao cho có thể hoạt động được trên các nền tảng khác nhau. Công nghệ hướng mô hình (MDE) là phương pháp tiếp cận mới giải quyết được sự phức tạp của các nền tảng khác nhau bằng cách tập trung vào diễn tả khía cạnh miền ứng dụng một cách hiệu quả. MDE hướng tới việc sử dụng các mô hình (models) như là tác nhân chính trong toàn bộ vòng đời phát triển của ứng dụng.

Và do đó, ở khía cạnh này nó cũng đồng nghĩa với thuật ngữ Phát triển hướng mô hình (MDD), và chúng ta có thể ngầm hiểu rằng khi nhắc đến MDE hay MDD là ta đang nói về “Công nghệ phát triển hướng mô hình”. MDD phát triển dựa trên ý tưởng về môi trường quản lý mô hình phần mềm có tính tự động hoá cao. Nghĩa là nó không bị phụ thuộc vào các nền tảng, và khi có nền tảng mới ra đời thì sự tự động hoá đó sẽ phát huy tác dụng, ứng dụng mới sẽ được chuyển đổi tự động từ các mô hình để tương thích với nền tảng mới. Điều đó làm tăng năng suất và thời gian phân phối sản phẩm.

Ngày nay, MDD không chỉ được ứng dụng trong lĩnh vực phần mềm mà còn ở những lĩnh vực khác như phần cứng [6] (mô hình các mạch điện tử để tạo các mạch vật lý ngoài sự can thiệp của con người), các hệ thống nhúng [10]. Phạm vi nghiên cứu được đề cập trong luận văn là lĩnh vực phần mềm, tương ứng với thuật ngữ “Công nghệ phát triển phần mềm hướng mô hình” (MDSE hay MDSD). Tiếp đó, ở Chương 3 luận văn sẽ trình bày phạm vi cụ thể hơn là miền ứng dụng Web (MDWE) với các phương pháp phát triển Web hướng mô hình, mà trọng tâm là phương pháp UWE. 1 TIEU LUAN MOI download : skknchat@gmail.1: Tập hợp miền ứng dụng và phương pháp trong MDD Như đã trình bày, mô hình (model) là điểm mấu chốt mà các phương pháp tiếp cận trong MDD hướng tới.

Trong đó mô hình phần mềm có thể được phân loại thành phi cấu trúc và cấu trúc [6], ví dụ mô hình phi cấu trúc như các mô tả bằng ngôn ngữ tự nhiên, các hình vẽ bằng công cụ đồ hoạ máy tính; mô hình cấu trúc thì có tập hợp các thành phần được định nghĩa trước và các quy tắc mà chúng tuân theo. Các quy tắc này có thể ở dạng phi hình thức (informally) hay dạng hình thức (formally). Các quy tắc được cung cấp dưới dạng hình thức được gọi là meta-model hay domain- specific language (DSL- ngôn ngữ phụ thuộc miền) hay modeling language (ngôn ngữ mô hình hoá), và được sử dụng bởi các phương pháp mô hình hoá khác nhau. Trên thị trường hiện tại có nhiều kiến trúc hướng mô hình (xem Hình 1.1) mà MDD tuân theo như MDA (chuẩn hoá bởi OMG sử dụng MOF), Software Factories 1 (phát triển bởi Microsoft sử dụng DSL), EMF (được tích hợp với Eclipse sử dụng Ecore), DSM (sử dụng DSL, phát triển bởi MetaCase 2 với công cụ MetaEdit+), vân vân.

Tuy nhiên, ở Chương này luận văn chỉ tập trung vào phân tích kiến trúc MDA. Kiến trúc tương tự với MDA, chỉ khác biệt một số điểm là EMF sẽ được đề cập ở Chương 2. Cả hai kiến trúc này đang được áp dụng rộng rãi bởi nhiều tổ chức hiện nay.2 Ứng dụng MDA trong quy trình phát triển phần mềm Mục này sẽ giải thích tại sao MDA có thể khắc phục được những nhược điểm mà các phương pháp truyền thống đang gặp phải. Về mặt bản chất, MDA không phải là quy trình phát triển phần mềm, và tư tưởng của MDA có thể áp dụng cho bất kỳ quy trình nào.

Cụ thể chúng ta sẽ so sánh phương pháp sử dụng MDA với phương pháp phát triển truyền thống trong quy trình phát triển theo mô hình thác nước.html 2 https://metacase.com/ 2 TIEU LUAN MOI download : skknchat@gmail.1 Phát triển phần mềm theo phương pháp truyền thống Đối với việc xây dựng những hệ thống nhỏ, ít tốn kém thì việc áp dụng các phương pháp truyền thống vẫn còn hữu dụng, tuy nhiên đối với việc xây dựng những hệ thống lớn, đòi hỏi phải đáp ứng nhiều tính năng từ phía người dùng, thì việc áp dụng các phương pháp này về lâu về dài sẽ gây nhiều khó khăn cho nhà phát triển. Yêu cầu Tài liệu dạng văn bản Phân tích Tài liệu dạng văn bản, biểu đồ Thiết kế Tài liệu dạng văn bản, biểu đồ Lập trình Mã nguồn Kiểm thử Mã nguồn Triển khai Hình 1.2: Phương pháp phát triển phần mềm truyền thống Hình trên minh họa các pha phát triển của mô hình thác nước, các pha phân tích, thiết kế mô tả các vấn đề hầu như dưới dạng văn bản, và hình ảnh minh họa là một số biểu đồ (UML) như biểu đồ ca sử dụng, biểu đồ lớp, biểu đồ hoạt động, vân vân. Đến pha lập trình thì một số vấn đề sẽ nảy sinh như nếu có những yêu cầu mới từ phía người dùng, thì thông thường nhà phát triển sẽ chú trọng nhiều hơn vào pha lập trình để đáp ứng nhanh nhu cầu của người dùng, thời gian hạn hẹp sẽ khiến nhà phát triển sao nhãng phần thiết kế, do đó khoảng cách giữa pha thiết kế và pha lập trình ngày càng lớn, tầm quan trọng của pha thiết kế sẽ giảm dần theo thời gian. Tuy việc cập nhật tài liệu sau khi lập trình có thể được giải quyết bằng các công cụ tạo tài liệu từ mã nguồn, tuy nhiên nó cũng chỉ giải quyết được việc thiết kế ở mức thấp, còn ở mức trừu tượng cao hơn như biểu diễn bằng các biểu đồ, ý nghĩa của nó thì các công cụ này không giải quyết được.

Điều này sẽ gây nhiều khó khăn cho việc kiểm thử, vận hành, bảo trì hệ thống sau này khi tài liệu thiết kế không được cập nhật đầy đủ. Ngoài vấn đề về thiết kế trên thì mô hình truyền thống này còn phải đối mặt với vấn đề khả năng tương thích ngược. Vì các công nghệ mới được phát minh theo 3 TIEU LUAN MOI download : skknchat@gmail.com thời gian một cách nhanh chóng nhằm đáp ứng các yêu cầu ngày một đa dạng của người dùng, để giải quyết những vấn đề tồn đọng trước đó, buộc các nhà phát triển phần mềm cũng phải chạy đua theo để không bị lạc hậu. Như vậy những phiên bản phần mềm mới có thể không tương thích với các công nghệ cũ, nền tảng cũ đã được dùng bởi mô hình truyền thống.2 Phát triển phần mềm theo phương pháp hướng mô hình (MDD) Phương pháp phát triển phần mềm hướng mô hình (MDSD) ít nhiều giải quyết được những vấn đề nêu trên.

Khi ứng dụng MDA vào quy trình phát triển theo mô hình thác nước, bản chất ở mỗi pha của quy trình là tài liệu được thể hiện ở dạng mô hình, và vì các mô hình này là mô hình hình thức (formal model) nên chúng có thể được hiểu bởi máy tính và được xử lý tự động. Yêu cầu Tài liệu dạng văn bản Phân tích PIM Thiết kế PSM Lập trình Mã nguồn Kiểm thử Mã nguồn Triển khai Hình 1.3: Ứng dụng MDA vào quy trình phát triển phần mềm Các mô hình được sử dụng bởi các công cụ chuyển đổi tự động từ nhiều nhà phát triển khác nhau để tạo ra các lược đồ (schemas), khung mã nguồn (code skeletons), mã tích hợp (integration code), và kịch bản triển khai (deployment scripts) cho nhiều nền tảng khác nhau được sử dụng trong một dự án. MDA định nghĩa mô hình độc lập nền (PIM), mô hình phụ thuộc nền (PSM), mô hình văn bản (Text), và cũng định nghĩa cách chúng liên kết với nhau. Một PIM được tạo ra, sau đó được chuyển đổi sang một hoặc nhiều PSM, để rồi được chuyển sang Text.

4 TIEU LUAN MOI download : skknchat@gmail.3 Những thuận lợi của kiến trúc hướng mô hình (MDA) 1.1 Chất lượng sản phẩm Điểm mấu chốt là người phát triển chú trọng vào việc phát triển PIM, vì vậy mà họ có thể làm việc một cách độc lập mà không phụ thuộc vào nền tảng đích, và có nhiều vấn đề kỹ thuật mà họ không cần quan tâm tới. Những vấn đề này sẽ tự động thêm vào bởi việc chuyển đổi từ PIM sang PSM, do đó nó sẽ cải thiện năng suất theo hai cách:  Người phát triển PIM sẽ làm ít việc hơn vì những chi tiết về nền tảng đích không cần được thiết kế. Tại mức mô hình PSM và Text (mã nguồn) sẽ được viết ít hơn vì lượng lớn mã nguồn được sinh tự động từ PIM, PSM.  Người phát triển có thể chuyển từ việc chú trọng vào viết mã nguồn sang việc thiết kế PIM, do đó họ sẽ để ý nhiều hơn việc giải quyết các vấn đề nghiệp vụ tại thời điểm đầu thiết kế, hay bảo trì nâng cấp phần mềm sau này, dẫn đến hệ thống sẽ phù hợp nhiều hơn với nhu cầu của người dùng, và người dùng cũng sẽ có được những tính năng tốt hơn trong khoảng thời gian ngắn hơn.2 Khả năng tương thích Ngoài ra xét đến khía cạnh tương thích ngược, thì từ một PIM có thể chuyển đổi sang nhiều PSM cho nhiều nền tảng khác nhau, do đó việc thiết kế PIM sẽ hoàn toàn tương thích với nền tảng mới sử công nghệ mới.

Mặt khác khi những công nghệ mới được phát minh trong tương lai, thì các tổ chức/công ty phần mềm cần cung cấp những công cụ chuyển đổi phù hợp, điều này cho phép chúng ta nhanh chóng triển khai hệ thống mới dựa trên nền tảng cũ (PIM).3 Khả năng tương tác PIM First First transformation transformation PSM Bridge PSM PSM Second Second transformation transformation Code Bridge Code Code Hình 1.4: Khả năng tương tác sử dụng các cầu nối trong MDA.3] 5 TIEU LUAN MOI download : skknchat@gmail.com Khi PSM được nhắm vào các nền tảng khác nhau, chúng không thể nói chuyện trực tiếp với nhau. Bằng cách nào đó chúng ta cần chuyển đổi các khái niệm từ một nền tảng thành các khái niệm được sử dụng ở nền tảng khác. Đây là những gì mà khả năng tương tác đề cập tới. MDA giải quyết vấn đề này bằng cách tạo ra các cầu nối (bridge) cần thiết giữa chúng.

Nếu chúng ta có thể chuyển đổi một PIM thành hai PSM được nhắm tới hai nền tảng, tất cả thông tin chúng ta cần để thu hẹp khoảng cách giữa hai PSM là đã có sẵn. Cụ thể, với mỗi thành phần trong PSM thứ nhất ta biết từ thành phần nào trong PIM mà nó đã được chuyển đổi.

Nội dung được bảo vệ bản quyền — Tải xuống đầy đủ