(LUẬN VĂN THẠC SĨ) Phương pháp hình thức trong việc phát triển hệ thống hướng đối tượng

Phương pháp phát triển phần mềm hướng đối tượng

Khái niệm

Xây dựng hệ thống phần mềm theo phương pháp hướng đối tượng bao gồm các bước phân tích, thiết kế và lập trình Phương pháp này tập trung vào việc sử dụng các đối tượng để tổ chức và quản lý mã nguồn, giúp tăng tính tái sử dụng và dễ bảo trì cho phần mềm.

3 nguyên tắc cơ bản: tính đóng gói, tính kế thừa và đa hình

Phân tích hướng đối tượng (OOA) là quá trình nghiên cứu và điều tra hệ thống nhằm hiểu rõ bài toán, xác định các đối tượng cần thiết để xây dựng các module của phần mềm Hoạt động này giúp phân tách bài toán thành các phần nhỏ hơn và xây dựng mô hình logic mô tả chức năng tổng thể của hệ thống.

Thiết kế hướng đối tượng (OOD) có nhiệm vụ mô hình hóa các đối tượng của bài toán thành các đối tượng phần mềm, đồng thời xây dựng mô hình kiến trúc và mô hình tính toán cho hệ thống Trong OOD, kiến trúc tập trung vào việc định nghĩa các đối tượng phần mềm và các tương tác giữa chúng.

Lập trình hướng đối tượng (OOP) kết hợp tri thức về quá trình với các khái niệm trừu tượng trong máy tính Nhiệm vụ quan trọng của giai đoạn này là chuyển đổi các đặc tả hệ thống đối tượng từ bản thiết kế thành mã máy thông qua các công cụ và ngôn ngữ lập trình OOP.

Các ưu điểm của phương pháp hướng đối tượng

Phương pháp hướng đối tượng và lập trình hướng đối tượng giúp giải quyết nhiều vấn đề trong quá trình phát triển phần mềm Những ưu điểm chính của phương pháp này bao gồm khả năng tổ chức mã nguồn hiệu quả, tái sử dụng mã, và dễ dàng bảo trì, từ đó nâng cao năng suất và chất lượng phần mềm.

Giúp nhà phát triển hình dung và ánh xạ các đối tượng của bài toán vào phần mềm, từ đó tạo ra hệ thống rõ ràng, dễ hiểu và thân thiện với người dùng.

Các đối tượng được thiết kế tốt trong hệ thống hướng đối tượng là nền tảng cho việc kết hợp các đơn thể tái sử dụng thành những hệ thống lớn hơn, giúp tối ưu hóa quy trình phát triển phần mềm.

- Lập trình hướng đối tượng, đặc biệt là kỹ thuật thừa kế cho phép loại bỏ những đoạn mã chung, làm tăng tính tái sử dụng

Quy ước truyền thông điệp giữa các đối tượng giúp mô tả giao diện giữa các thành phần trong hệ thống và các hệ thống bên ngoài một cách dễ dàng Điều này cũng tạo điều kiện thuận lợi cho việc phân chia công việc trong dự án, mang lại sự rõ ràng và tự nhiên hơn.

Nguyên lý che dấu thông tin đóng vai trò quan trọng trong việc xây dựng các hệ thống thông tin an toàn, giúp bảo vệ dữ liệu nhạy cảm Thiết kế dựa vào dữ liệu là phương pháp hiệu quả, phù hợp với ngữ nghĩa của mô hình trong quá trình cài đặt, đảm bảo tính an toàn và bảo mật cho hệ thống.

- Định hướng đối tượng cung cấp cho chúng ta những công cụ hỗ trợ để giải quyết được độ phức tạp của bài toán.

Tiến trình thống nhất

Khái niệm về tiến trình thống nhất

Tiến trình phát triển phần mềm bao gồm các hoạt động thiết yếu nhằm biến đổi yêu cầu của người sử dụng thành một hệ thống phần mềm đáp ứng đầy đủ các tiêu chí đã đề ra.

Hình 1 Tiến trình phát triển phần mềm

Tiến trình thống nhất (RUP – Rational Unified Process) là một phương pháp phát triển phần mềm do Rational Software phát triển và duy trì RUP cung cấp một khung làm việc linh hoạt, có thể được điều chỉnh cho từng loại hệ thống phần mềm, phù hợp với các lĩnh vực ứng dụng, kiểu tổ chức, mức độ hoàn thiện và quy mô dự án khác nhau.

Tiến trình thống nhất trong phát triển phần mềm dựa trên các thành phần, cho thấy rằng hệ thống phần mềm được tạo ra từ những thành phần riêng biệt, kết nối với nhau thông qua các giao diện đã được xác định trước.

Tiến trình thống nhất sử dụng ngôn ngữ mô hình hóa thống nhất UML là phương pháp quan trọng trong thiết kế hệ thống phần mềm RUP (Rational Unified Process) hỗ trợ tối ưu việc áp dụng UML, trong đó UML trở thành một phần không thể thiếu trong RUP.

Hiện nay RUP được rất nhiều công cụ hỗ trợ tự động trên phần lớn tiến trình.

Các đặc trưng của tiến trình thống nhất

RUP có 3 đặc trưng cơ bản: [6], [21]:

- Ca sử dụng điều khiển tiến trình phát triển

- RUP lấy kiến trúc làm trung tâm

- Là tiến trình lặp và tăng dần

Phần sau đây sẽ trình bày chi tiết hơn từng đặc trưng trên

I.2.2.1 Ca sử dụng điều khiển tiến trình phát triển

Một hệ thống phần mềm được phát triển nhằm phục vụ người dùng, trong đó người dùng bao gồm cả những người sử dụng hệ thống và các hệ thống khác tương tác với dịch vụ mà chúng ta xây dựng.

Một ca sử dụng là phần chức năng của hệ thống giúp người dùng đạt được kết quả mong muốn Các ca sử dụng đóng vai trò quan trọng trong việc nắm bắt yêu cầu chức năng, và khi được tập hợp lại, chúng tạo thành mô hình ca sử dụng, mô tả toàn diện chức năng của hệ thống Mô hình này thay thế cho các đặc tả chức năng truyền thống, trong khi đặc tả thường trả lời câu hỏi về hình thức của hệ thống, ca sử dụng lại tập trung vào việc hệ thống sẽ phục vụ nhu cầu của từng người sử dụng như thế nào.

Ca sử dụng không chỉ là công cụ mô tả yêu cầu hệ thống mà còn điều khiển các tiến trình thiết kế, cài đặt và kiểm thử Nó phản ánh các yêu cầu cần thiết để cung cấp dịch vụ cho người sử dụng, từ đó tạo ra giá trị gia tăng Dựa trên mô hình ca sử dụng, các nhà phát triển xây dựng một loạt mô hình phân tích, thiết kế và cài đặt ở các mức độ khác nhau, từ khái niệm đến logic và vật lý, nhằm đảm bảo tính phù hợp trong việc thực hiện mô hình ca sử dụng đã được thiết lập.

Hình 2 Ca sử dụng điều khiển các hoạt động phát triển

Người kiểm tra sẽ xem xét các cài đặt để đảm bảo rằng các thành phần của mô hình cài đặt đã được thực hiện đúng theo các ca sử dụng Điều này cho thấy rằng ca sử dụng đóng vai trò quan trọng trong việc điều khiển quá trình phát triển, với việc phát triển tuân theo các luồng công việc được xác định bởi ca sử dụng.

I.2.2.2 Tiến trình thống nhất lấy kiến trúc làm trung tâm

Kiến trúc hệ thống phần mềm đóng vai trò như khung nền cho quá trình xây dựng và phát triển phần mềm Khái niệm này bao gồm các khía cạnh tĩnh và động quan trọng, được phát triển dựa trên yêu cầu của tổ chức và cảm nhận của người dùng, cùng với các bên liên quan thông qua các ca sử dụng Nó cũng bị ảnh hưởng bởi nhiều yếu tố như môi trường nền, các khối xây dựng tái sử dụng, các yếu tố triển khai và yêu cầu phi chức năng như tính khả thi và độ tin cậy Kiến trúc phần mềm cung cấp một cái nhìn tổng thể về các đặc điểm quan trọng nhất của hệ thống, trong khi tạm gác lại các chi tiết cụ thể.

Ca sử dụng và kiến trúc có mối quan hệ chặt chẽ, với mọi sản phẩm đều bao gồm chức năng và hình thức thể hiện Để đạt được kết quả tốt nhất, hai yếu tố này cần được cân bằng Chức năng tương ứng với các ca sử dụng, trong khi hình thức thể hiện liên quan đến kiến trúc Việc lựa chọn các ca sử dụng để phát triển cần được định hướng theo kiến trúc, đảm bảo sự phù hợp và hỗ trợ cho việc thực hiện các ca sử dụng từ giai đoạn đầu của hệ thống và trong tương lai Thực tế cho thấy, cả kiến trúc và ca sử dụng đều phát triển song song.

Kiến trúc hệ thống đóng vai trò quan trọng trong việc quản lý các khung nhìn khác và điều khiển quá trình phát triển hệ thống một cách tăng dần và lặp lại trong suốt chu kỳ sống của phần mềm Nó bao gồm một tập hợp các quyết định thiết yếu liên quan đến thiết kế và cấu trúc của hệ thống.

- Tổ chức của hệ thống phần mềm

- Lựa chọn các phần tử cấu trúc và giao diện cho hệ thống

- Hành vi của chúng thể hiện trong hợp tác giữa các phần tử

- Tập hợp các phần tử cấu trúc và hành vi vào hệ con lớn hơn

Hình 3 Mô hình hoá kiến trúc hệ thống

Kiến trúc hệ thống phần mềm chuyên sâu được thể hiện qua các khung nhìn tương tác, mỗi khung nhìn phản ánh tổ chức và cấu trúc của hệ thống, đồng thời tập trung vào những khía cạnh cụ thể khác nhau.

I.2.2.3 Tiến trình thống nhất là tiến trình lặp và tăng dần

Phát triển phần mềm là một quá trình phức tạp, đòi hỏi nhiều công việc trong một khoảng thời gian nhất định Để quản lý hiệu quả, việc chia nhỏ công việc thành các dự án con là cần thiết, mỗi dự án này đóng vai trò như một bước lặp, góp phần vào sự tăng trưởng chung Phát triển phần mềm hướng đối tượng giúp dễ dàng thực hiện điều này nhờ vào cấu trúc các thành phần độc lập Để đạt được hiệu quả tối ưu, các bước lặp cần phải được điều khiển và thực hiện theo kế hoạch đã định sẵn.

Khi cài đặt một bước lặp, cần chú ý đến hai yếu tố chính: đầu tiên, bước lặp phải liên quan đến các ca sử dụng nhằm mở rộng tính khả dụng của hệ thống trong quá trình phát triển; thứ hai, nó cần phải tập trung vào việc giải quyết những rủi ro quan trọng nhất.

Mỗi bước lặp tiếp theo được xây dựng dựa trên các kết quả từ bước lặp trước, với việc tiếp tục thực hiện phân tích, thiết kế, cài đặt và kiểm thử cho các chức năng còn lại trong các ca sử dụng Mặc dù ở giai đoạn đầu, các nhà phát triển có thể chỉ thay thế thiết kế sơ bộ bằng một thiết kế chi tiết hơn mà chưa tạo ra sự tăng trưởng sản phẩm, nhưng sự phát triển này sẽ trở nên rõ ràng và cần thiết trong các bước lặp sau.

Trong mỗi vòng lặp thiết kế, nhà thiết kế xác định các ca sử dụng, xây dựng thiết kế dựa trên kiến trúc đã chọn và triển khai thành các thành phần Họ kiểm tra sự tương thích giữa các thành phần và ca sử dụng Nếu vòng lặp đạt được mục tiêu, có thể tiến tới vòng lặp tiếp theo; nếu không, nhà thiết kế cần xem xét lại quyết định trước đó và thử nghiệm phương pháp mới.

Một dự án được coi là thành công khi thực hiện đúng theo kế hoạch đã đề ra và hạn chế tối đa các vấn đề chưa được nhận thức Mục tiêu chính của việc này là giảm thiểu rủi ro trong quá trình triển khai dự án.

Vòng đời của một tiến trình thống nhất

Hình 4 Một vòng đời hệ thống với các pha và bước lặp

Vòng đời phát triển phần mềm bao gồm bốn pha chính: sơ bộ (inception), chi tiết (elaboration), xây dựng (construction) và chuyển giao (transition) Mỗi pha được chia thành nhiều bước lặp nhỏ, trong đó mỗi bước lặp thực hiện các công việc như lập mô hình nghiệp vụ, xác định yêu cầu, phân tích, thiết kế, triển khai và kiểm thử để hoàn thành một sản phẩm phần mềm Nội dung và khối lượng công việc của các bước lặp trong mỗi pha có sự khác biệt đáng kể so với các pha khác.

Hình 5 Luồng công việc trong các pha và các bước lặp khác nhau

Một tiến trình tích hợp

Tiến trình thống nhất là một phương pháp phát triển phần mềm dựa trên thành phần, sử dụng ngôn ngữ mô hình hóa thống nhất UML Nó tập trung vào ba ý tưởng chính: ca sử dụng, kiến trúc, và phát triển lặp lại và tăng dần Để thực hiện tiến trình này, cần xem xét nhiều yếu tố như vòng đời, giai đoạn, dòng công việc, giảm rủi ro, kiểm soát chất lượng, quản lý dự án và quản lý cấu hình Tiến trình thống nhất cung cấp một khung làm việc tích hợp, cho phép các nhà phát triển và nhà xây dựng công cụ phát triển các công cụ tự động hóa, hỗ trợ các dòng công việc cụ thể, và xây dựng các mô hình khác nhau, đồng thời tích hợp công việc qua các vòng đời và mô hình khác nhau.

Ngôn ngữ hình thức trong phát triển phần mềm

Mục tiêu của việc áp dụng phương pháp hình thức

Phương pháp hình thức giúp ích cho tất cả các công việc của quá trình làm phần mềm:

Việc áp dụng phương pháp hình thức trong các ngôn ngữ có tính toán học chính xác giúp làm rõ yêu cầu của khách hàng, đồng thời loại bỏ những sự nhập nhằng, không nhất quán và thiếu sót trong thông tin.

Thiết kế hệ thống yêu cầu sử dụng các ngôn ngữ hình thức, cho phép các nhà thiết kế mô tả cấu trúc hệ thống và các mối quan hệ giữa các thành phần Điều này giúp làm rõ từng bước trong quá trình phát triển hệ thống.

Bằng cách sử dụng các công cụ toán học trong ngôn ngữ hình thức, chúng ta có thể xác minh tính chính xác của hệ thống, đảm bảo rằng nó đáp ứng đầy đủ các yêu cầu đã được xác định.

Nhà phát triển và khách hàng sử dụng đặc tả và sản phẩm để thẩm định xem sản phẩm có đáp ứng các yêu cầu hay không Đồng thời, ngôn ngữ hình thức cũng hỗ trợ việc thiết kế các ca kiểm thử (test case) một cách hiệu quả.

- Làm tài liệu: Sự rõ ràng, chính xác của ngôn ngữ hình thức còn được sử dụng trong các tài liệu cho các giai đoạn phát triển phần mềm.

Ưu điểm của phương pháp hình thức

Với tính rõ ràng, chính xác chặt chẽ phương pháp hình thức mang lại những ưu điểm sau cho việc phát triển phần mềm:

Ngôn ngữ hình thức có khả năng nâng cao chất lượng và năng suất phần mềm bằng cách cải thiện khả năng hiểu chính xác hệ thống Nó giúp phát hiện lỗi sớm, thậm chí ngay từ giai đoạn đặc tả, cho phép mô hình hóa và phân tích trực tiếp trên mô hình Điều này tạo điều kiện cho việc giả lập, thực thi và chứng minh thông qua ngôn ngữ hình thức.

- Có thể chứng minh: một hệ thống được chứng minh đúng đắn chỉ có thể dựa vào ngôn ngữ hình thức

- Rất hữu ích cho các hệ thống đòi hỏi độ tin cậy cao

Phương pháp hình thức giúp phát hiện lỗi sớm trong các giai đoạn đầu như đặc tả yêu cầu, phân tích và thiết kế, từ đó giảm chi phí sửa đổi phần mềm Việc áp dụng phương pháp này không chỉ nâng cao chất lượng sản phẩm mà còn tối ưu hóa chi phí cho các dự án phát triển phần mềm.

Ngôn ngữ đặc tả hình thức

Ngôn ngữ đặc tả hình thức bao gồm cú pháp và ngữ nghĩa, với các tính chất quan trọng như không nhập nhằng, nhất quán, đầy đủ và khả năng suy luận.

Các loại ngôn ngữ đặc tả hình thức:

- Ngôn ngữ đặc tả tiên đề: VDM, Anna, Z

- Ngôn ngữ đặc tả chuyển trạng thái: StateCharts, ASLAN, Paisley, InaJo, Special

- Ngôn ngữ đặc tả mô hình hóa trừu tượng: VDM, Z, RAISE, B [29]

- Ngôn ngữ đặc tả đại số: OBJ, Larch, Clear, Anna

- Ngôn ngữ đặc tả logic thời gian, đồng thời: CSP, GIL, Petri nets, statecharts.

Mục tiêu và nội dung của đề tài

Trong những năm gần đây, phương pháp hướng đối tượng và phương pháp hình thức đã trở thành hai hướng tiếp cận quan trọng trong ngành công nghệ phần mềm, mặc dù chúng vẫn tồn tại khoảng cách và tính độc lập nhất định Mục tiêu của đề tài là nghiên cứu các ngôn ngữ hình thức, từ đó lựa chọn và áp dụng một ngôn ngữ phù hợp vào quá trình phát triển phần mềm hướng đối tượng Trên cơ sở đó, chúng tôi đã tiến hành xây dựng một công cụ hỗ trợ cho việc đặc tả hình thức hóa hệ thống phần mềm hướng đối tượng.

Đề tài này tập trung vào việc đặc tả hệ thống hướng đối tượng bằng ngôn ngữ rCOS, sau đó chuyển đổi đặc tả thành thiết kế cuối cùng thông qua các phép biến đổi đại số và luật đã được chứng minh Hệ thống đặc tả có các khái niệm tương đồng với biểu đồ lớp trong mô hình UML, giúp dễ dàng chuyển đổi sang dạng biểu diễn UML, từ đó có thể sinh mã lệnh cho ngôn ngữ lập trình hướng đối tượng bằng các công cụ như Rational Rose hay Power Designer.

ĐẶC TẢ VÀ LÀM MỊN HỆ THỐNG ĐỐI TƯỢNG VỚI rCOS

rCOS – Một phép làm mịn hệ thống đối tượng

rCOS (refinement Calculus of Object System) là một mô hình ngữ nghĩa quan hệ và phép làm mịn, được thiết kế cho phát triển hệ thống phần mềm hướng đối tượng và hướng thành phần Mô hình này được phát triển bởi các nhà nghiên cứu He Jifeng, Zhiming Liu và Xiaoshan Li tại UNU-IIST, dựa trên lý thuyết lập trình thống nhất (UTP) của Hoare và He rCOS cung cấp công cụ hỗ trợ cho việc phân tích và mô hình hóa phần mềm, bao gồm cả phần mềm dựa trên trạng thái và phần mềm hướng sự kiện.

II.1.1 UTP – cơ sở của rCOS

UTP hình thức hóa khái niệm ngôn ngữ lập trình và kỹ thuật lập luận thông qua logic vị từ và đại số quan hệ Mỗi chương trình được coi là mối quan hệ nhị phân giữa lệnh và trạng thái của các biến, với các lệnh thực thi ảnh hưởng đến trạng thái chương trình Trong UTP, Hoare và He đề xuất một mô hình dựa trên trạng thái để mô tả một lệnh hoặc bước chuyển bằng bộ (α, P).

α là tập hợp các biến trong chương trình, thường được gọi là bảng chữ cái, và được chia thành ba nhóm Nhóm đầu tiên bao gồm các biến toàn cục và cục bộ, được ký hiệu bằng ký tự alphabet để biểu diễn các biến toàn cục trong chương trình, với định dạng {x1: T1, x2: T2, …, xn: Tn}, trong đó Ti là kiểu dữ liệu của biến xi.

Locar biểu diễn các biến cục bộ trong phạm vi lệnh, trong khi nhóm thứ hai cung cấp thông tin ngữ cảnh liên quan đến các lớp (kiểu của đối tượng) và các mối quan hệ giữa chúng.

CNAME biểu diễn tập các lớp

Superclass là hàm một phần ánh xạ một lớp tới lớp cha của nó o Nhóm thứ ba miêu tả cấu trúc các lớp:

Attr(N) biểu diễn tập các thuộc tính (thừa kế hoặc khai báo) của lớp N: {a1 ặ (U 1 , c 1 ), … a m ặ (U m , c m )} với U i là kiểu giỏ trị và c i là giá trị khởi tạo của biến a i

Visible(N) là tập các thuộc tính có thể nhìn thấy (public) của N.

Meth(N) biểu diễn tập các thuộc tính public của N {m1 ặ (),…mk ặ ()}.

Intmeth(N) biểu diễn tập các thuộc tính trong được khai báo ở N và được định nghĩa giống op(N).

Cặp vị từ P xác định mối quan hệ giữa các giá trị ban đầu và kết quả của biến trong chương trình, được biểu diễn qua công thức Pre ⊢ Post, cụ thể hơn là p(x) ⊢ R(x, x’) Trong đó, p(x) là tiền điều kiện cần có giá trị true trước khi chương trình bắt đầu, còn R(x, x’) là hậu điều kiện thu được sau khi thực hiện chương trình Các ký hiệu x và x’ đại diện cho giá trị khởi đầu và kết thúc của biến x, trong khi ok và ok’ là các biến logic mô tả trạng thái hành vi ban đầu và cuối của chương trình; nếu chương trình được kích hoạt hợp lệ thì ok là true, và nếu thực hiện thành công thì ok’ cũng là true, ngược lại sẽ là false.

II.1.2 Đặc tả hệ thống đối tượng bằng rCOS

Dùng những lý thuyết UTP, các tác giả của rCOS [15], [9] đề xuất một mô hình tính toán trong đó:

Một đối tượng có thể mang kiểu của kiểu con mà nó được khai báo, điều này thể hiện rõ ràng tính đa hình trong hệ thống lập trình hướng đối tượng.

Một lệnh thao tác có thể áp dụng không chỉ cho các biến kiểu nguyên thủy mà còn cho các đối tượng do người dùng định nghĩa Để đảm bảo rằng các biến được truy cập một cách hợp lệ, framework ngữ nghĩa cần liên kết các lệnh với tập hợp các trạng thái khả truy cập hiện tại của chúng.

Hệ thống đối tượng bao gồm các khai báo lớp và lệnh có dạng cdecls ● Main, trong đó cdecls xác định các lớp và dịch vụ của đối tượng Main được cấu thành từ cặp (externalvar, c), mô tả hành vi của các đối tượng và tương tự như phương thức main trong các ngôn ngữ lập trình như Java và C++.

Quy ước các ký hiệu:

- CNAME được dùng để ký hiệu tập tên các lớp có trong đặc tả hệ thống Tên các lớp thương được ký hiệu bởi các chữ cái C, D, M, N

- ANAME là tập các tên thuộc tính của một lớp N ∈ CNAME

- VNAME là tập các biến x, y, x… trong một phạm vi nào đấy (chương trình, phương thức…)

Phần khai báo lớp Cdecls là một thứ tự khai báo hữu hạn các lớp cdecl 1 ;….;cdecl k trong đó mỗi lớp cdecl i có dạng:

[private] class N [extends M] { private T t = a , T t = a ; 1 1 1 m m m protected U u = b , U u = b ; 1 1 1 n n n public V v = d , V v = d ; 1 1 1 k k k method m (T x , T y , T z ) { c }; m (T x , T y , T z ) { c } 1 11 11 12 12 13 13 1 ℓ ℓ1 ℓ1 ℓ2 ℓ2 ℓ3 ℓ3 ℓ

Mỗi lớp trong lập trình có thể được khai báo là private hoặc public, với mặc định là public Chỉ những lớp có kiểu public hoặc kiểu cơ sở mới có thể được sử dụng trong các khai báo biến chung glb.

- N và M là các tên lớp khác nhau và M được gọi là lớp cha của N

Trong phần private, lớp khai báo các thuộc tính riêng tư, bao gồm kiểu dữ liệu và giá trị khởi tạo Tương tự, các thuộc tính protected và public được khai báo trong các phần protected và public của lớp.

Phần method trong lớp N khai báo các phương thức m1, m2, , mℓ, trong đó (T i1 x i1), (T i2 y i2), (T i3 z i3) và ci đại diện cho các tham số giá trị, tham số kết quả, tham số giá trị-kết quả và thân phương thức mi Phương thức được biểu diễn dưới dạng m(paras){c}, với paras là các tham số và c là thân lệnh của m Để đơn giản, lớp N có thể được ký hiệu là N[parent, pri, pro, pub, op], trong đó N là tên lớp, parent là tập các lớp cha (có thể rỗng), và pri, pro, pub lần lượt đại diện cho các thuộc tính private, protected và public, còn op là tập các phương thức của lớp N Các ký hiệu tương ứng như parent(N), pri(N), prot(N), pub(N), op(N) cũng được sử dụng để chỉ các thuộc tính liên quan đến lớp N.

II.1.2.2 Mô tả biểu thức

Trong ngôn ngữ lập trình hướng đối tượng, biểu thức có thể xuất hiện ở phía bên phải của các lệnh gán, tuân theo các quy tắc nhất định Cụ thể, biểu thức được định nghĩa như sau: e ::= x | null | self | e.a | e is C | C(e) | f(e).

Trong lập trình, x là biến đơn và null là kiểu đối tượng đặc biệt, được coi là lớp con của mọi lớp Null là duy nhất trong ngữ cảnh này Từ khóa self được sử dụng để chỉ đến đối tượng đang hoạt động trong phạm vi hiện tại Ngoài ra, e.a đại diện cho thuộc tính a của đối tượng e, trong khi e is C xác định kiểu kiểm thử, với C(e) là biểu thức kiểm tra tương ứng.

II.1.2.3 Mô tả lệnh rCOS không chỉ hỗ trợ mô tả cấu trúc các ngôn ngữ lập trình hướng đối tượng mà còn cho phép mô tả các lệnh thông thường, lệnh sẽ tác động lên trạng thái các biến α của chương trình c ::= skip | chaos | var T x = e | end x (bỏ qua | không xác định| khai báo | kết thúc khai.báo) c; c | cYbZc | c ⊓ c | b*c (tuần tự | chọn theo điều kiện | không tiền định | lặp) le.m(e, v, u) | le:=e | C.new(x) (gọi phương thức | gán| tạo đối tượng mới) Ở đây b là biểu thức logic, c là lệnh, e là một biểu thức, le có thể xuất hiện ở vế trái của phép gán và có dạng le ::= x|le.a với x là biến đơn còn a là thuộc tính của đối tượng Đa số các lệnh có ý nghĩa tương tự như trong các ngôn ngữ lệnh (có thể xem chi tiết trong [15], [16]) Sau đây là các giải thích một số lệnh đặc trưng cho chương trình hướng đối tượng

Lệnh gán le := e được coi là hợp lệ khi cả le và e đã được xác định và kiểu của e là kiểu con của kiểu đã khai báo cho le Đối với lệnh gán đơn x := e, khi lệnh này hợp lệ, nó chỉ đơn giản thay đổi giá trị của x thành giá trị của e Trong trường hợp thay đổi thuộc tính của đối tượng, lệnh le.a := e sẽ cập nhật thuộc tính a của đối tượng le bằng giá trị e.

Một tiến trình phát triển đặc tả hệ thống hướng đối tượng

Tiến trình RUP đã áp dụng nhiều mô hình UML trong phát triển phần mềm hướng đối tượng, bao gồm mô hình nghiệp vụ hệ thống với biểu đồ ca sử dụng, mô hình phân tích với biểu đồ lớp khái niệm, mô hình thiết kế logic với các biểu đồ công tác và trạng thái, cũng như mô hình thiết kế với biểu đồ lớp thiết kế Việc sử dụng đa dạng khung nhìn trong mô hình hóa hệ thống giúp trực quan hóa quá trình phát triển và quản lý hiệu quả Tuy nhiên, sự khác biệt giữa các mô hình trong các giai đoạn phát triển có thể gây khó khăn, đặc biệt là tính nhất quán giữa các mô hình cùng loại và khác loại không được đảm bảo Một số nghiên cứu đã đề xuất giải pháp cho những vấn đề này.

1) Đảm bảo tính nhất quán ngang của các mô hình con khác nhau trong các pha khác nhau

2) Đảm bảo tính nhất quán dọc của mô hình qua các bước làm mịn của một pha

3) Đảm bảo tính lần vết được của mô hình giữa hai pha: từ pha này sang pha sau và ngược lại Nhờ tính chất này mà nhà phân tích, thiết kế có thể luôn kiểm tra và đối sánh chúng theo cả chiều xuôi và chiều ngược để đảm bảo sự nhất quán giữa chúng

4) Đảm bảo tính tích hợp được của các mô hình Sự tích hợp này cho phép đánh giá sự nhất quán và đồng bộ toàn hệ thống ở mỗi bước trước khi sang bước sau

Các giải pháp nêu trên nhằm giải quyết sự đồng bộ và nhất quán trong hệ thống, hạn chế tình trạng thiếu nhất quán RUP bắt đầu từ khung nhìn nghiệp vụ với mô hình lớp khái niệm và kết thúc bằng biểu đồ lớp thiết kế trước khi chuyển sang mã nguồn Việc sử dụng một khung nhìn duy nhất qua các biểu đồ lớp có thể khắc phục tính đa khung nhìn của RUP Để giải quyết những nhược điểm còn lại, tiến trình phát triển mới chỉ dựa vào một khung nhìn duy nhất, từ hệ khởi thảo đến hệ thống kết quả cuối cùng.

Hình 7 Ý tưởng cho phương pháp giải quyết vấn đề

Để xây dựng các phép biến đổi và quy tắc kiểm tra tính đúng đắn của chúng, cần thực hiện một loạt các phép biến đổi chính xác Qua đó, chúng ta có thể chuyển đổi biểu đồ lớp khái niệm ban đầu thành biểu đồ lớp thiết kế cuối cùng cho phần mềm hệ thống.

Trong phương pháp này, các khung nhìn của RUP sẽ được áp dụng như những công cụ hỗ trợ nhằm xác định các phép biến đổi cần thiết.

Để đạt được biểu đồ lớp thiết kế cuối cùng, cần thực hiện các phép biến đổi như thêm lớp, thuộc tính và phương thức, cũng như thay đổi đặc trưng của chúng và liên kết giữa các lớp Mỗi hệ thống ở bước tiếp theo phải nhất quán và đồng bộ với bước trước, do đó cần giải quyết hai vấn đề quan trọng.

- Phải đặc tả hệ thống như thế nào để có thể kiểm tra sự nhất quán của nó ở mỗi bước

- Các phép biến đổi trên cần thực hiện như thế nào để đảm bảo phép biến đổi là đúng đắn

Hướng giải quyết hai vấn đề này đã được đề xuất trong các nghiên cứu [1] và

Việc kiểm chứng tính đúng đắn của các phép biến đổi có thể thực hiện qua các phương pháp hình thức như rCOS Quá trình này được chia thành hai phạm vi: kiểm chứng tĩnh để xác nhận tính đúng đắn trong một mô hình và kiểm chứng động để đánh giá tính phù hợp của đặc tả hệ thống trong hai bước biến đổi liên tiếp Nhờ đó, hệ thống đặc cuối cùng sẽ đảm bảo tính chính xác hoàn toàn.

II.2.2 Các bước của tiến trình

II.2.2.1 Xây dựng hệ thống khởi tạo

Mô hình hệ thống khởi tạo, hay còn gọi là mô hình khái niệm thô, là một mô hình miền lĩnh vực, giúp mô tả các khái niệm quan trọng của hệ thống thông qua các đối tượng trong lĩnh vực nghiệp vụ và mối liên kết giữa chúng Bước này tương ứng với việc phát triển mô hình nghiệp vụ hệ thống trong quy trình RUP, cho phép sử dụng RUP để hỗ trợ trong việc xác định các lớp khái niệm thông qua phân tích các ca sử dụng.

Công việc đầu tiên trong tiến trình phát triển hệ thống là tạo mô hình khởi tạo, bao gồm việc bổ sung tên các lớp N_i đại diện cho các đối tượng trong miền lĩnh vực vào biểu đồ lớp của mô hình hệ thống, với cấu trúc APP_0 = N_1 []; N_2 []; ; N_k [] Đồng thời, cần xác định các quan hệ giữa các lớp khái niệm N_i Phép biến đổi này được thực hiện thông qua thuật toán addClassName.

// Thuật toán AddClassName- bổ sung các lớp vào mô hình //Input: Hệ thống S = (α, P), xâu tên lớp N

//Output: Hệ thống mới S’ = (α’, P’) với S thuộc CNAME AddClassName (S, N)

Output: Lớp N trống (chưa có các thuộc tính hoặc phương thức) Format: addClassName ()

1 Nếu N là xâu trống hoặc N thuộc CNAME thì sang 3

II.2.2.2 Làm mịn đặc tả hệ thống qua các bước

Sau khi hoàn thành đặc tả hệ thống ban đầu APP 0, nhà phát triển tiến hành thực hiện liên tiếp n bước làm mịn để đạt được đặc tả hệ thống lớp thiết kế cuối cùng APP n.

Bài viết này trình bày một quy trình làm mịn chính, có thể linh hoạt điều chỉnh để đạt được một đặc tả chính xác Các bước a, b, c đã được nghiên cứu và chứng minh trong tài liệu [15], với các luật làm mịn cơ bản và phổ biến Tác giả đề xuất bổ sung các luật làm mịn liên quan đến các mối quan hệ giữa các lớp và các ràng buộc của luật này trong phần d Bước đầu tiên là bổ sung các thuộc tính cho lớp.

Khi tạo một lớp, việc xác định và bổ sung các thuộc tính private cùng với việc định dạng kiểu dữ liệu cho chúng là rất quan trọng Theo quy tắc, các thuộc tính trong lớp mặc định là private nếu không có giả thiết nào khác Để thêm một thuộc tính thành phần vào lớp, chúng ta cần tuân theo các quy tắc bổ sung cụ thể.

Trong đó, T đại diện cho một kiểu dữ liệu và d là giá trị khởi đầu của thuộc tính attributeName (có thể không có) Đối với mỗi lớp, cần thực hiện nhiều lần quy tắc này để bổ sung đầy đủ các thuộc tính Quá trình này có thể được mô tả bằng một thuật toán hình thức.

//Input: Hệ thống S, C ∈ CNAME, newAatt {T x = d}

//Output: Hệ thống mới S’ = (α’, P) trong đó newAatt ∈ pri(C)

1 Nếu C ∉ CNAME thì sang bước 4

2 Nếu tên x không hơp lệ hoặc newAatt ∈ attr(C)thì sang bước 4

Thực hiện k lần thuật toán này để bổ sung các thuộc tính cho k lớp của hệ thống b) Chuyên đổi dạng thuộc tính

Để hỗ trợ nhiều dịch vụ hơn, các thuộc tính kiểu private cần được chuyển sang kiểu protected Điều này sẽ được thực hiện thông qua việc áp dụng luật chuyển đổi kiểu thuộc tính.

N i [pri ∪ {T x = d}, prot]; cdecls ⊑ N i [pri, prot ∪ {T x = d}]; cdecls

Việc chuyển thuộc tính kiểu private trong một lớp sang kiểu protected theo thuật toán sau:

// Thuật toán PriAttToproAtt, chuyển kiểu thuộc tính private thành protected

//Algorithm ChangeAttPriToPro //Input: S, C ∈ CNAME, attr ∈ pri(C)

Kết chương

Tiến trình phát triển RUP là một trong những phương pháp phổ biến để phát triển phần mềm hướng đối tượng Tuy nhiên, các nhà phát triển thường gặp khó khăn trong việc đảm bảo tính nhất quán của các mô hình và khả năng tích hợp các khung nhìn Một giải pháp hiệu quả là áp dụng một tiến trình phát triển phần mềm hướng đối tượng mới, kết hợp với một khung nhìn duy nhất, nhằm khắc phục những vấn đề này.

Mô hình quan hệ ngữ nghĩa của rCOS có khả năng đặc tả hệ thống hướng đối tượng và chứng minh các luật làm mịn Quy trình biến đổi làm mịn hệ thống theo các luật của rCOS đảm bảo tính đúng đắn nhờ vào việc các bước làm mịn đã được kiểm chứng Việc kiểm chứng tính đúng đắn của các phép biến đổi được thực hiện ở hai mức: mức tĩnh trong một đặc tả hệ thống và mức động giữa hai đặc tả của hệ thống qua các bước làm mịn trước sau.

XÂY DỰNG CÔNG CỤ

Đặt vấn đề

Trong chương II, chúng tôi đã đề cập đến nghiên cứu về quy trình phát triển phần mềm hướng đối tượng, sử dụng các luật và thuật toán làm mịn trên đặc tả khung nhìn lớp Đối với các hệ thống lớn, việc thu thập đặc tả thiết kế lớp hoàn chỉnh đòi hỏi khối lượng công việc lớn do sự gia tăng số lượng lớp và các đặc trưng của chúng, bao gồm thuộc tính và phương thức, cũng như sự phức tạp trong các mối quan hệ giữa chúng Ví dụ, với một hệ thống đơn giản gồm 5 lớp, mỗi lớp có 5 thuộc tính và 5 phương thức, cần ít nhất 113 biến để đặc tả hệ thống Con số này sẽ tiếp tục tăng lên theo từng biến đổi Do đó, nếu thực hiện quy trình phát triển này bằng tay, sẽ rất khó khăn và dễ dẫn đến sai sót, chỉ phù hợp cho các bài toán nhỏ Vì vậy, việc phát triển công cụ hỗ trợ cho quy trình này trở thành một nhu cầu cấp thiết và có ý nghĩa thực tiễn.

Các nghiên cứu dưới đây là những kết quả ban đầu trong việc phát triển công cụ hỗ trợ tự động hóa quy trình phát triển hệ thống hướng đối tượng đã được nêu.

Phân tích hệ thống

III.2.1 Xác định yêu cầu

Công cụ này hỗ trợ phát triển phần mềm hướng đối tượng thông qua khung nhìn biểu đồ lớp, cho phép người dùng thực hiện các thao tác thêm và biến đổi các thành phần của biểu đồ Giao diện người dùng trực quan với ký pháp UML giúp người dùng dễ dàng chỉ ra yêu cầu bằng cách vẽ biểu đồ theo đồ họa chuẩn Công cụ sẽ tự động thực hiện các phép biến đổi theo các luật và ràng buộc để đảm bảo tính chính xác của hệ thống Người dùng có thể chuyển đổi từ biểu đồ lớp khái niệm ban đầu sang biểu đồ lớp thiết kế cuối cùng thông qua các thao tác cơ bản như thêm lớp (có kế thừa), thêm thuộc tính, thêm phương thức, và thay đổi mối quan hệ giữa các lớp.

Công cụ cần phải có khả năng quản lý các tệp đặc tả hệ thống, cho phép người dùng tạo mới hệ thống, mở tệp của hệ thống đã có và lưu trữ chúng để sử dụng sau này Các chức năng của công cụ được mô tả chi tiết trong bảng 3.

R.1.1 Tạo tệp hệ thống mới

R.1.2 Lưu tệp hệ thống đang dùng

R.1.3 Mở tệp hệ thống đã có

R.1.3 Xuất đặc tả ra file có định dạng chung để có thể tương tác với công cụ CASE khác

R.2 Phát triển và làm mịn đặc tả hệ thống

R.2.1 Thêm lớp (có thể kế thừa) vào hệ thống

R.2.2 Xóa lớp của hệ thống

R.2.3 Chọn một lớp từ hệ thống đang mở

R.2.4 Thêm thuộc tính của lớp được chọn

R.2.6 Thay đổi đặc trưng của thuộc tính của lớp được chọn

R.2.7 Thay đổi đặc trưng của phương thức của lớp được chọn

R.2.8 Xóa thuộc tính/phương thức của lớp được chọn

R.2.9 Thêm mới quan hệ giữa hai lớp của hệ thống đang mở

R.2.10 Thay đổi mối quan hệ giữa hai lớp của hệ thống đang mở

R 2.11 Xóa một quan hệ giữa hai lớp của hệ thống đang mở

Bảng 3 Bảng tổng hợp chức năng của công cụ

III.2.2 Phát triển biểu đồ miền lĩnh vực

Trong phần này, chúng ta sẽ xem xét các thành phần khái niệm trong công cụ của mình Theo chuẩn đặc tả MOF của OMG, các khái niệm của UML được mô tả thông qua kiến trúc 4 lớp trừu tượng hóa: meta-metamodel, meta-metadata, metadata và data, với lớp cuối cùng là lớp mà người dùng UML sử dụng để mô hình hóa các hệ thống Chuẩn MOF này cho phép OMG sử dụng các ký pháp của chính mình để mô tả, định nghĩa và tổ chức dữ liệu.

Hệ thống của chúng ta chỉ liên quan đến các khái niệm của biểu đồ lớp UML, vì vậy chúng ta sẽ tập trung vào đặc tả kiến trúc thượng tầng của biểu đồ lớp Các lớp khái niệm trong hệ thống sẽ được đặt tên tương tự như trong biểu đồ Một đặc tả hệ thống (MetaClass) bao gồm nhiều thành phần, có thể là các thành phần lớp (Class) hoặc các thành phần quan hệ giữa các lớp (Relationship) Mỗi lớp có một tập thuộc tính (Property) và một tập phương thức (Operation).

Hình 9 Gói mô tả các khái niệm thuộc biểu đồ lớp UML theo OMG

TIEU LUAN MOI download : skknchat@gmail.com

Hình 10 Biểu đồ khái niệm miền lĩnh vực

III.2.3 Xây dựng các mô hình ca sử dụng

III.2.3.1 Mô hình ca sử dụng mức gộp

Hai thao tác chính R1 và R2 trong bảng phân tích yêu cầu tương ứng với hai ca sử dụng mức gộp Manage MetaClass và Refine MetaClass (hình 11)

Hình 11 Biểu đồ ca sử dụng mức gộp

III.2.3.2 Biểu đồ ca sử dụng chi tiết Ở mức này ta phân rã hai ca sử dụng mức gộp thành 2 gói ca sử dụng: quản lý tệp đặc tả hệ thống (hình 12) và làm mịn một đặc tả hệ thống (hình 13)

Hình 12 Biểu đồ ca sử dụng quản lý các đặc tả hệ thống

Trong quá trình sử dụng đặc tả để làm mịn hệ thống, công cụ cần kiểm tra các ràng buộc theo luật làm mịn sau mỗi thao tác của người dùng, đồng thời cung cấp cảnh báo hoặc ngăn chặn các thao tác không hợp lệ Mặc dù việc xóa các thành phần đặc tả như lớp, phương thức, và thuộc tính không thuộc vào quy trình làm mịn, nhưng công cụ vẫn nên hỗ trợ tính năng này để giúp người dùng sửa lỗi trong quá trình thao tác.

Hình 13 Biểu đồ ca sử dụng phát triển và làm mịn đặc tả hệ thống

III.2.4 Phát triển các biểu đồ lớp khái niệm

Người dùng tương tác với hệ thống thông qua các lớp giao diện như Management Boundary và Operation Boundary để thực hiện các thao tác như tạo mới, mở, lưu và làm mịn biểu đồ Các lớp điều khiển Management Control và Operation Control hỗ trợ người dùng trong việc thao tác trên giao diện và thực hiện các tác vụ biến đổi bên trong hệ thống Những thay đổi này được lưu vào lớp thực thể System Specification, sử dụng các yếu tố từ UML Element và File Management Object.

Hình 14 Biểu đồ lớp khái niệm tổng quát

Thiết kế hệ thống

III.3.1 Biểu đồ lớp thiết kế

Từ biểu đồ lớp khái niệm và các phân tích ta đi đến biểu đồ lớp thiết kế cho hệ thống

Bằng thao tác tổng quát hóa, ta có lớp Element là lớp trừu tượng cha của hai lớp

Sau khi thêm các thuộc tính và phương thức cho các lớp thiết kế, lớp MetaClass sẽ sử dụng phương thức Draw() để vẽ toàn bộ biểu đồ, thông qua việc gọi phương thức Draw() của các thành phần trong biểu đồ Mẫu thiết kế FactoryMethod được áp dụng để tổng quát hóa quy trình vẽ các thành phần của biểu đồ.

Để lưu biểu đồ lớp thành các file, lớp MetaClass đã được bổ sung phương thức SaveToFile() Ngược lại, phương thức tĩnh LoadToFile() cho phép mở biểu đồ từ file XML đã lưu trước đó Để quản lý menu lệnh và thanh công cụ của hệ thống một cách hiệu quả, đồng thời hỗ trợ chức năng Undo – Redo cho các thao tác, chúng tôi áp dụng mẫu thiết kế Command.

The methods MetaClass:AddClass, MetaClass:AddRelationship, Class:Rename, Class:ChangeVisibility, Class:AddProperty, Class:RemoveProperty, Class:AddOperation, Class:RemoveOperation, Property:ChangeVisibility, and Operation:ChangeVisibility are executed according to the smoothing algorithms for class models outlined in the previous sections (see Figure 15).

AddClass () AddRelationship () RemoveClass () RemoveRelationship () LoadFromFile () SaveToFile () Draw ()

: void : void : int : int : MetaClass : String : void

: System.Array : System.Array : String : Rectangle +

Rename () ChangeVisibility () AddProperty (Property pro) RemoveProperty () AddOperation (Operation op) RemoveOperation () Draw ()

: void : void : void : int : void : int : void

: String : String : String : System.Array + ChangeVisibility (String newVisibility) : void

Hình 15 Biểu đồ lớp thiết kế của hệ thống

III.3.2 Biểu diễn thông tin đặc tả hệ thống

Việc biểu diễn thông tin đặc tả hệ thống là một vấn đề quan trọng trong xây dựng công cụ, đòi hỏi cơ chế thuận tiện để biểu diễn, đọc và lưu trữ các đặc tả hệ thống Cần chuyển đổi đặc tả từ dạng đối tượng trong bộ nhớ thành cấu trúc dữ liệu bên ngoài để dễ dàng lưu trữ và trao đổi Bên cạnh đó, cần chú ý đến các tiêu chuẩn của các công cụ CASE hiện nay để đảm bảo khả năng chuyển dữ liệu giữa các công cụ xây dựng và các phần mềm phổ biến như Rational Rose, PowerDesigner.

III.3.2.2 XML và XMI a) Ngôn ngữ XML

Ngôn ngữ XML được thiết kế để mô tả dữ liệu và có nhiều điểm tương đồng với UML, cho phép biểu diễn thông tin đặc tả của hệ thống hướng đối tượng một cách hiệu quả.

Hình 16 So sách cách định nghĩa XML và UML của OMG

Một văn bản XML chỉ được coi là đúng định dạng khi tuân thủ cấu trúc cú pháp, nhưng để đảm bảo tính hợp lệ và mang thông tin ngữ nghĩa cần thiết, văn bản đó cần phải đáp ứng các tiêu chí định dạng và ngữ nghĩa theo yêu cầu Theo W3C, DTD hoặc XML schema (lược đồ XML) có thể được sử dụng để quy định cấu trúc, nội dung và ngữ nghĩa của tài liệu XML XML schema là một tài liệu XML nhằm mô tả tài liệu XML khác, do đó được gọi là tài liệu siêu dữ liệu Một tài liệu XML đúng định dạng và tuân thủ thông tin mô tả trong lược đồ XML sẽ được gọi là tài liệu XML hợp lệ.

XMI (XML Metadata Interchange) là chuẩn của OMG dùng để trao đổi thông tin siêu dữ liệu qua XML Chuẩn này được áp dụng cho các siêu dữ liệu có thể được biểu diễn bằng Meta-Object Facility (MOF) XMI thường được sử dụng để trao đổi thông tin trong các mô hình UML và để tuần tự hóa các đối tượng thành dãy bit hoặc ký tự.

Tư tưởng thiết kế của OMG tập trung vào việc phân chia dữ liệu thành các mức mô hình trừu tượng và thực Mô hình trừu tượng thể hiện thông tin ngữ nghĩa, trong khi mô hình thực cung cấp các biểu đồ trực quan Các mô hình trừu tượng được xây dựng từ các ngôn ngữ mô hình tùy ý, dựa trên MOF như UML hoặc SysML.

Mục đích của XMI là tạo điều kiện thuận lợi cho việc chuyển đổi siêu dữ liệu giữa các công cụ mô hình hóa dựa trên UML, đồng thời hỗ trợ các kho dữ liệu chuẩn MOF trong các môi trường phân tán không đồng nhất.

Currently, popular UML tools in the market, such as Rational Rose, PowerDesigner, and Enterprise Architect, support XMI, enabling seamless data exchange through XMI files.

III.3.2.3 Lựa chọn phương án

Để quản lý file đặc tả hệ thống và các ký pháp đồ họa UML, tôi đã quyết định lưu trữ và đọc toàn bộ thông tin trong một file duy nhất Các thao tác này được thực hiện thông qua quá trình tuần tự hóa và khôi phục, cho phép lưu một đối tượng thành file và khôi phục lại thông tin từ file đó Công cụ FM Tool được phát triển nhằm trao đổi dữ liệu đặc tả với các công cụ CASE khác, sử dụng chuẩn XMI để xuất thông tin đặc tả ra file XML File XML này có thể được sử dụng để đọc và khôi phục toàn bộ thông tin về đặc tả hệ thống, từ đó hỗ trợ thực hiện các thao tác như biến đổi, làm tài liệu, và sinh mã khung chương trình tự động.

Hiện nay, các công cụ CASE phổ biến trên thị trường thường lưu trữ thông tin mô hình dưới dạng file định dạng riêng và hỗ trợ chức năng nhập/xuất (import/export) đặc tả thông qua XMI Vì vậy, phương án mà chúng tôi lựa chọn hoàn toàn tuân thủ các tiêu chuẩn và xu hướng chung trong ngành.

Cài đặt thử nghiệm

III.4.1 Môi trường và công cụ

Công cụ FM Tool được phát triển theo quy trình RUP, sử dụng phần mềm CASE Rational Rose Các sản phẩm từ các pha và giai đoạn phân tích thiết kế đã được trình bày trong phần trước.

Trong quá trình lập trình, nhằm đáp ứng nhu cầu thử nghiệm và phát triển nhanh chóng, chúng tôi đã quyết định sử dụng ngôn ngữ Visual C# trên nền tảng Microsoft NET.

2005 – một khung làm việc (framework) hỗ trợ khá tốt cho các hệ thống hướng đối tượng và các ứng dụng winform

Ngoài ra, chúng tôi còn sử dụng thư viện DocToolkit để thực hiện các thao tác với thanh công cụ và thực đơn

III.4.2 Công cụ FM Tool

Hình 17 Giao diện công cụ FM Tool

Chúng tôi đã hoàn thành quy trình và phát triển thành công công cụ FM Tool (hình 17), với các chức năng được mô tả chi tiết trong phần III.2.1.

Quản lý đặc tả hệ thống a)

Giao diện của FM Tool rất đơn giản và dễ sử dụng, với menu và thanh công cụ quen thuộc, giúp người dùng thực hiện các thao tác tạo, lưu và mở tệp hệ thống một cách dễ dàng.

Tạo tệp hệ thống mới: chọn menu File

- ặ New hoặc ấn nỳt New ở thanh cụng cụ

Lưu tệp hệ thống: chọn menu File

- ặ Save hoặc ấn nỳt Save ở thanh cụng cụ

Mở tệp hệ thống đã có: chọn menu File

- ặ Open hoặc ấn nỳt Open ở thanh công cụ

Để xuất đặc tả hệ thống sang định dạng XMI, bạn có thể chọn tùy chọn "Export to XMI" từ menu File hoặc nhấn nút "Export to XMI" trên thanh công cụ Bên cạnh đó, cần phát triển và làm mịn đặc tả hệ thống để đảm bảo tính chính xác và hiệu quả.

Sử dụng FM Tool, người dùng có thể thực hiện các thao tác để có thể phát triển một hệ thống phần mềm hướng đối tượng:

Để bổ sung các thành phần như lớp và mối quan hệ giữa các lớp vào đặc tả hệ thống, người dùng chỉ cần nhấp vào thanh công cụ và vẽ các đối tượng tương ứng trong phần thể hiện ký pháp đồ họa.

Người dùng có thể dễ dàng thay đổi vị trí và kích thước của các ký pháp đồ họa trong FM Tool bằng cách thực hiện các thao tác kéo thả đơn giản, tương tự như trong các công cụ CASE khác.

You can modify the components and properties of a layer by right-clicking on the specific component and selecting "Properties" from the popup menu This action will display the modification form for your adjustments.

- Để xóa một thành phần: click phải chuột vào thành phần và chọn Delete hoặc ấn phím Delete

Trong biểu diễn ký pháp đồ họa về tầm nhìn của các thuộc tính và phương thức của lớp, chúng tôi quy định rằng: private được ký hiệu bằng dấu trừ (-), protected bằng dấu thăng (#) và public bằng dấu cộng (+) trước thuộc tính hoặc phương thức (hình 17).

Hình 18 Sửa đồi đối tượng bằng cách nhấn phải chuột và chọn Properties

Hình 19 Form sửa đổi các thuộc tính của một lớp

Tiến hành một case study với FM Tool

Trường đại học tổ chức các seminar chuyên môn cho sinh viên, với nhiều nhóm tham gia, mỗi nhóm tập trung vào một chủ đề lớn như công nghệ phần mềm hay mạng máy tính, và có giảng viên phụ trách Các seminar diễn ra theo lịch cố định hàng tuần trong một khoảng thời gian nhất định Nhà trường yêu cầu phát triển một ứng dụng quản lý seminar, bao gồm chức năng tạo nhóm seminar, chỉ định giáo viên, công bố thông tin và cho phép sinh viên đăng ký tham dự.

Trong phần này, chúng tôi tiến hành xây dựng hệ thống theo quy trình đã trình bày ở phần II.2.1, sử dụng các luật và thuật toán làm mịn thông qua FM Tool Nếu có thao tác vi phạm các luật làm mịn, công cụ sẽ thông báo và ngăn chặn thực hiện Mục đích của case study này là thử nghiệm lý thuyết và công cụ, vì vậy chúng tôi chỉ tập trung vào việc xây dựng các chức năng cơ bản và đơn giản nhất có thể.

III.5.1 Khởi tạo hệ thống

Dựa trên tiến trình RUP, việc phân tích bài toán bắt đầu từ mô hình nghiệp vụ, đặc biệt là mô hình khái niệm miền lĩnh vực, dẫn đến việc khởi tạo hệ thống APP 0 với các lớp Seminar, Student và Teacher.

APP 0 = {Seminar[], Student[], Teacher[], RELATIONSHIP}

RELATIONSHIP = { relation(association, join, Student, Seminar, 1 *, 0 *), relation(association, supervise, Teacher, Seminar, 1 1, 0 *)}

Hình 20 Khởi tạo hệ thống cho đặc tả APP 0

III.5.2 Bổ sung các thuộc tính

Các lớp trong APP 0 chưa có thuộc tính nào, qua phân tích nghiệp vụ ta thấy cần bổ sung các thuộc tính sau:

The Seminar class includes several key attributes: a private DateTime variable for the start time of the seminar group, a private DateTime variable for the end time, a private String to describe the weekly schedule, and a private String for the seminar topic.

- Lớp Teacher: o Private String TeacherID o Private String name o Private String rank //chức danh khoa học o Private String department //bộ môn hoặc phòng ban trực thuộc

- Lớp Student: o Private String StudentID o Private String name o Private String class //lớp quản lý của sinh viên

Theo thuật toán ở phần II.2.2.2.c thì (hình 21)

Hình 21 Mô hình UML tương ứng với APP 1

III.5.3 Bổ sung các phương thức

Từ đặc tả APP 1 ta thêm các phương thức vào các lớp để thu được APP 2 (hình

- Lớp Seminar: o Public SetTeacher(Teacher t)

- Lớp Teacher: o Public PrintInfo() //In thông tin giáo viên ra màn hình

- Lớp Student: o Public PrintInfo() //In thông tin sinh viên ra màn hình o Public RegisterSeminar(Seminar s) //đăng ký tham dự seminar

Hình 22 Mô hình UML tương ứng với APP 2

Trong quá trình phân tích, chúng ta nhận thấy rằng hai lớp Teacher và Student đều có thuộc tính name và phương thức PrinInfo() Điều này cho phép chúng ta tổng quát hóa hai thực thể này bằng danh từ "Person" Vì vậy, chúng ta sẽ thêm lớp Person vào hệ thống và thiết lập quan hệ tổng quát hóa từ lớp Teacher và Student đến lớp Person Đồng thời, thuộc tính name của hai lớp này sẽ được chuyển lên lớp cha Person.

Làm mịn hệ thống theo định hướng mẫu thiết kế giúp cải thiện cấu trúc của hệ thống Bằng cách áp dụng mẫu Strategy, chúng ta có thể chuyển phương thức PrintInfo() từ các lớp Teacher và Student lên lớp cha Mẫu Strategy thể hiện rõ tính đa hình trong lập trình hướng đối tượng, với các thuật toán MoveMethod và Polymorphism được áp dụng Kết quả sau bước này là đặc tả hệ thống APP 3, được làm mịn từ APP 2, thể hiện mối quan hệ APP 3 ⊑ APP 2.

Hình 23 Mô hình UML tương ứng với APP3

III.5.5 Chuyển đặc tả sang công cụ CASE khác

Dùng chức năng xuất ra XMI của FM Tool, đặc tả APP3 được chuyển sang công cụ PowerDesigner rất chính xác

: string : string : string + PrintInfo () : string

: int : int : string : string + SetTeacher () : void

Hình 24 Đặc tả được chuyển sang công cụ Power Designer

Nội dung file XML theo chuẩn XMI được xuất ra từ FM Tool trong Case Study này được trình bày trong phần phụ lục.

Hai hướng sử dụng FM Tool

Sau khi có được đặc tả hệ thống cuối cùng, nhà phát triển có thể tiến hành công việc sinh mã nguồn khung chương trình bằng 1 trong 2 cách (hình 25):

- Chuyển đặc tả từ FM Tool sang công cụ CASE khác thông qua XMI

- Sinh mã nguồn từ FM Tool (Chức năng này chúng tôi sẽ phát triển sau)

Phát triển và làm mịn đặc tả với FM Tool

Sinh mã nguồn bằng FM Tool (sẽ phát triển sau) Xuất đặc tả từ FM Tool ra XMI

Nhập đặc tả bằng XMI vào công cụ CASE khác Thực hiện một số thao tác với công cụ CASE khác

Sinh mã nguồn bằng công cụ CASE khác

Hình 25 Biểu đồ hoạt động hai phương án sinh mã nguồn sau khi có đặc tả hệ thống trong FM Tool

Kết luận chương

Việc phát triển FM Tool là nỗ lực hiện thực hóa phần mềm hướng đối tượng theo phương pháp hình thức, cung cấp một công cụ thực tiễn với các chức năng cơ bản Công cụ này cho phép tạo ra đặc tả thiết kế hệ thống dưới dạng XML, tương thích với mô hình lớp thiết kế UML Nhờ đó, người dùng có thể dễ dàng chuyển đổi thiết kế sang các ngôn ngữ lập trình hướng đối tượng bằng cách sử dụng các công cụ như Rational Rose Quy trình chuyển đổi đặc tả sang công cụ khác được thực hiện tự động qua hai bước: xuất đặc tả theo chuẩn XMI ra file XML và nhập vào các công cụ khác từ file xuất ra của FM Tool.

Công cụ hiện tại chỉ hỗ trợ các phép biến đổi cơ bản, trong khi nhiều phép biến đổi phức tạp hơn vẫn chưa được đề cập, như hiện thực hóa giao diện và các phép biến đổi trên phương thức Trong tương lai, chúng tôi sẽ nghiên cứu và phát triển thêm các thuật toán mới, đồng thời tích hợp chức năng sinh mã lập trình cho mô hình thiết kế cuối cùng Điều này nhằm giúp người sử dụng tự động hóa việc tạo khung mã chương trình trong các ngôn ngữ lập trình hướng đối tượng hiện đại như Java và C#.