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 xác định và sử dụng các đối tượng, giúp tối ưu hóa quá trình phát triển phần mềm và nâng cao khả năng tái sử dụng mã nguồn.
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 để phát triển các module phần mềm Quá trình 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 trong 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) giúp kết hợp tri thức về các quá trình với các khái niệm trừu tượng trong máy tính Nhiệm vụ của giai đoạn này là chuyển đổi các đặc tả hệ thống đối tượng từ 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, đặc biệt là lập trình hướng đối tượng, giúp giải quyết nhiều vấn đề trong 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ì hệ thống.
Giúp nhà phát triển hình thành tư duy á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.
Những đối tượng được thiết kế tốt trong hệ thống hướng đối tượng là nền tảng quan trọng để kết hợp các đơn thể tái sử dụng thành các hệ thống lớn hơn Điều này giúp tối ưu hóa quy trình phát triển phần mềm và nâng cao khả năng mở rộng của hệ thống.
- 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 đơn thể trong hệ thống và các hệ thống bên ngoài một cách dễ dàng hơn Điều này cũng tạo điều kiện cho việc phân chia công việc trong dự án trở nên tự nhiên và dễ hiểu 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 trên dữ liệu 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 bảo mật và hiệu quả 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
Quá trình phát triển phần mềm bao gồm chuỗi 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í đã được đặt 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 tùy chỉnh cho từng loại hệ thống phần mềm, 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, nghĩa là hệ thống được xây dựng từ những phần mềm kết nối qua các giao diện đã được xác định trước.
Tiến trình thống nhất UML là công cụ quan trọng trong thiết kế hệ thống phần mềm, giúp tối ưu hóa quy trình phát triển RUP hỗ trợ việc áp dụng UML một cách hiệu quả, với UML trở thành một phần không thể thiếu trong RUP, đảm bảo tính đồng nhất và chất lượng trong thiết kế phần mềm.
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, bao gồm cả người 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 (use case) là chức năng hệ thống cung cấp cho người dùng để đạt được kết quả cụ thể Các ca sử dụng giúp nắm bắt yêu cầu chức năng và tạo thành mô hình ca sử dụng, mô tả đầy đủ 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, với câu hỏi trọng tâm là: hệ thống sẽ làm gì cho từng người sử dụng?
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 yêu cầu hệ thống cần thực hiện để cung cấp dịch vụ cho người dùng, mang lại giá trị gia tăng Dựa trên mô hình ca sử dụng, các nhà phát triển tạo ra nhiều 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ý, đảm bảo mỗi mô hình tương thích với việc thực hiện mô hình ca sử dụng đã xây dựng.
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ẽ xác minh các cài đặt để đảm bảo rằng các thành phần của mô hình cài đặt phù hợp với 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, nghĩa là quá trình phát triển phải 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ư một khung nền cho việc xây dựng và phát triển phần mềm Khái niệm kiến trúc phần mềm bao gồm các khía cạnh tĩnh và động quan trọng đối với hệ thố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 tổ chức 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 cân nhắc triển khai và yêu cầu phi chức năng như tính thể hiện 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ề những đặc điểm quan trọng nhất của hệ thống, bỏ qua các chi tiết nhỏ.
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 Hai yếu tố này cần được cân bằng để đạt kết quả tối ưu, trong đó chức năng gắn liền với các ca sử dụng và hình thức thể hiện liên quan đến kiến trúc Việc lựa chọn 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 Kiến trúc phải tạo điều kiện cho việc thực hiện các ca sử dụng từ đầu quá trình 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ò then chốt 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 theo cách tăng dần và lặp lại trong suốt vòng đời của phần mềm Nó bao gồm các quyết định quan trọng liên quan đến cấu trúc và tổ chứ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
Hệ thống phần mềm chuyên sâu được mô tả 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 Mỗi khung nhìn tập trung vào một khía cạnh cụ thể, giúp làm rõ các yếu tố khác nhau của hệ thống.
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 yêu cầu khối lượng công việc lớn và thời gian nhất định Việc chia nhỏ công việc thành các dự án con là cần thiết, với mỗi dự án con đại diện cho một bước lặp, góp phần vào sự phát triển tổng thể Phương pháp phát triển phần mềm hướng đối tượng hỗ trợ điều này nhờ vào các thành phần độc lập có thể kết hợp với nhau Để đạt hiệu quả tối ưu, các bước lặp cần được quản lý chặt chẽ và thực hiện theo kế hoạch đã định.
Khi cài đặt trong một bước lặp, cần xem xét hai yếu tố quan trọng: đầu tiên, bước lặp phải liên quan đến một nhóm 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, bước lặp cần 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 trong quá trình phát triển dự án đều dựa trên các kết quả từ bước lặp trướ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 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 Tuy nhiên, ở các bước sau, sự phát triển của sản phẩm trở nên cần thiết và không thể thiếu.
Trong quá trình lặp, người 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 thiết kế 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à các ca sử dụng Nếu một bước lặp đạt yêu cầu, có thể tiến hành bước tiếp theo; nếu không, cần xem xét lại các 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ới sự lệch hướng tối thiểu Mục tiêu chính của việc giảm rủi ro là tối thiểu hóa các vấn đề chưa được nhận thức, giúp dự án đi đúng quỹ đạo.
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ộ, chi tiết, xây dựng và chuyển giao 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 cần thiết để hoàn thiện một sản phẩm phần mềm, bao gồm 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ử Tuy nhiên, nội dung và khối lượng công việc của các bước lặp giữa các pha là khác nhau.
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 dựa trên thành phần, sử dụng ngôn ngữ mô hình hoá thống nhất UML và 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 Quá trình này yêu cầu xem xét nhiều khía cạnh 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 Nó cung cấp một khung làm việc tích hợp, cho phép nhà phát triển và người xây dựng công cụ tạo ra các công cụ hỗ trợ tự động hoá, phục vụ cho 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 vòng đời và các mô hình.
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 với các ngôn ngữ toán học chính xác giúp làm rõ yêu cầu của khách hàng, loại bỏ những thông tin không nhất quán và thiếu đầy đủ.
Thiết kế hệ thống sử dụng các ngôn ngữ hình thức để giúp các nhà thiết kế mô tả cấu trúc của hệ thống, xác định mối quan hệ giữa các thành phần và tối ưu hóa từng bước trong quy 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 chỉ định.
Nhà phát triển và khách hàng tiến hành thẩm định sản phẩm dựa trên đặc tả và sản phẩm thực tế để xác định xem sản phẩm có đáp ứng yêu cầu hay không Hơn nữa, ngôn ngữ hình thức cũng hỗ trợ trong việc thiết kế các ca kiểm thử (test case).
- 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 sự hiểu biết chính xác về hệ thống Điều này giúp phát hiện lỗi sớm, thậm chí ngay từ giai đoạn đặc tả, đồng thời cho phép mô hình hóa và phân tích trực tiếp trên mô hình Ngoài ra, ngôn ngữ hình thức còn hỗ trợ giả lập, thực thi và chứng minh, từ đó tối ưu hóa quy trình phát triển phần mềm.
- 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
Giảm giá thành phần mềm thông qua việc 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ế, giúp giảm thiểu chi phí sửa đổi và nâng cao hiệu quả phát triển.
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: C SP, 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 những khoảng cách và sự độc lập nhất định Do đó, mục tiêu của đề tài này 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ữ vào quy trình phát triển phần mềm hướng đối tượng Trên cơ sở đó, chúng tôi sẽ 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 đó áp dụng các phép biến đổi đại số và luật đã được chứng minh để chuyển đổi đặc tả thành thiết kế cuối cùng 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, điều này giúp dễ dàng chuyển đổi sang biểu diễn thiết kế UML Từ đó, có thể sinh mã lệnh cho ngôn ngữ lập trình hướng đối tượng thông qua các công cụ như Rational Rose và 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 phát triển bởi He Jifeng, Zhiming Liu và Xiaoshan Li tại UNU-IIST, nhằm hỗ trợ quá trình 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 dựa trên lý thuyết lập trình thống nhất (UTP) của Hoare và He, cho phép phân tích và mô hình hóa hiệu quả cả phần mềm dựa trên trạng thái lẫn 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 các 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 biến, trong đó các lệnh được thực hiện tác động đến trạng thái của 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ộ, trong đó ký hiệu alphabet thể hiện tập hợp các biến toàn cục trong chương trình dưới dạng {x1: T1, x2: T2, , xn: Tn}, với 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 về các lớp, bao gồm 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).
P là cặp vị từ xác định mối quan hệ giữa các giá trị ban đầu của biến và các giá trị kết quả của nó, biểu diễn dưới dạng Pre ⊢ Post, cụ thể hơn là p(x) ⊢ R(x, x’) Trong đó, p(x) là tiền điều kiện, yêu cầu 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 nhận được sau khi chương trình thực hiện Biến x và x’ đại diện cho giá trị khởi đầu và kết thúc của biến x trong chương trình Các biến logic ok và ok’ 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ệ, ok là true, và nếu thực hiện chương trình thành công, ok’ là true; ngược lại, chúng 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 lớp 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 truy cập vào các biến 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 thể hiện phần khai báo các lớp và xác định dịch vụ của các đối tượng, còn main là cặp (externalvar, c) mô tả hành vi của các đối tượng, 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 kiểu mặc định là public Chỉ những lớp được khai báo là public hoặc các lớp 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
Phần private trong 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 phần protected và public được sử dụng để khai báo các thuộc tính bảo vệ và công khai 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, ký hiệu N[parent, pri, pro, pub, op] được dùng để biểu diễn lớp, trong đó N là tên lớp, parent là tập hợp các lớp cha (có thể rỗng), và pri, pro, pub là tập hợp các thuộc tính private, protected và public, còn op là tập hợp các phương thức của lớp N Các ký hiệu tương ứng parent(N), pri(N), prot(N), pub(N), op(N) cũng mang ý nghĩa tương tự và chỉ các ký hiệu 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 và được xác định theo các quy tắc sau: e ::= x | null | self | e.a | e is C | C(e) | f(e).
Trong lập trình, biến đơn được ký hiệu là x, trong khi null là một kiểu đối tượng đặc biệt Lớp NULL là lớp con của mọi lớp, và null là duy nhất Từ khóa self được sử dụng để chỉ đối tượng trong phạm vi hiện tại, e.a đại diện cho thuộc tính a của đối tượng e Kiểu kiểm thử được ký hiệu là C, và C(e) được sử dụng để kiểm tra đối tượng e.
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 | c Y b Z c | 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 chỉ được xác định chính xác khi cả le và e đều đã được khai báo đúng và kiểu của e là kiểu con của kiểu le Đối với lệnh gán đơn x := e, khi lệnh gán này hợp lệ, nó chỉ 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
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 mô hình thiết kế với biểu đồ lớp thiết kế Việc sử dụng đa khung nhìn trong mô hình hóa hệ thống giúp trực quan hóa và quản lý quy trình phát triển Tuy nhiên, sự khác biệt giữa các khung nhìn 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 Nhiều nghiên cứu đã chỉ ra các vấn đề này và đề xuất giải pháp để cải thiện.
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 vấn đề đồng bộ và nhất quán trong hệ thống, với hai giải pháp đầu tiên tập trung vào việc tạo ra cơ chế kiểm soát Nhận xét về RUP, chúng ta thấy rằng quy trình này 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 chỉ sử dụng một khung nhìn duy nhất thông qua các biểu đồ lớp sẽ giúp khắc phục tính đa khung nhìn của RUP Để giải quyết những nhược điểm hiện có, quy trình phát triển mới chỉ dựa trên một khung nhìn duy nhất, được thể hiện qua các biểu đồ lớp, để phát triển hệ thống từ giai đoạn khởi thảo đến 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 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 cách tiếp cận này, các khung nhìn của RUP sẽ được sử dụng như công cụ hỗ trợ để 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 (có thể kế thừa), thêm thuộc tính và phương thức cho lớp trong hệ thống, cũng như thay đổi đặc trưng của thuộc tính và phương thức hoặc thay đổi liên kết giữa các lớp Mỗi hệ thống ở bước sau 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 chứng minh 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 Kiểm chứng tính đúng đắn đượ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 qua hai bước biến đổi liên tiếp Nhờ đó, hệ thống đặc cuối cùng đạt được sẽ hoàn toàn chính xác.
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ô hình miền lĩnh vực, thể hiện 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ụ trong quy trình RUP, cho phép sử dụng RUP để hỗ trợ xác định các lớp khái niệm thông qua việc phân tích các ca sử dụng.
Công việc đầu tiên trong tiến trình là tạo mô hình khởi tạo của hệ thống bằng cách bổ sung tên các lớp N i vào biểu đồ lớp, thể hiện các đối tượng miền lĩnh vực Mô hình hệ thống có dạng APP 0 = N 1 []; N 2 []; ; N k [], đồng thời 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 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.
Để đạt được một đặc tả đầy đủ và chính xác, có thể áp dụng linh hoạt các bước làm mịn chính Các bước a, b, c đã được trình bày và chứng minh trong nghiên cứu [15], trong đó các luật làm mịn này là những quy tắc cơ bản và phổ biến Luận văn này đề xuất bổ sung luật làm mịn nhằm cải thiệ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 (phần d) Bước a bao gồm việc bổ sung các thuộc tính cho lớp.
Khi tạo một lớp, cần xác định và bổ sung các thuộc tính private cùng với việc định dạng các kiểu dữ liệu cho chúng Mặc định, các thuộc tính trong lớp sẽ là private trừ khi có giả thiết khác Để thêm một thuộc tính thành phần vào lớp, ta có thể áp dụng các quy tắc bổ sung phù hợp.
T là một kiểu dữ liệu, và d là giá trị khởi đầu có thể không có của thuộc tính attributeName Đối với mỗi lớp, quy tắc này được thực hiện nhiều lần để 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
Để nâng cao khả năng hỗ trợ các dịch vụ, cần chuyển các thuộc tính kiểu private sang kiểu protected Điều này sẽ được thực hiện bằng cách á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 phương pháp nổi tiếng trong phát triển phần mềm hướng đối tượng, nhưng 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 Để khắc phục những vấn đề này, việc áp dụng một tiến trình phát triển phần mềm hướng đối tượng mới dựa trên một khung nhìn duy nhất kết hợp với RUP có thể là một giải pháp hiệu quả.
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 Quá trình biến đổi làm mịn theo các luật của rCOS đảm bảo tính đúng đắn của hệ thống, 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 diễn ra ở 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.
XÂY DỰNG CÔNG CỤ
Đặt vấn đề
Trong chương II, chúng tôi đã trình bày một tiến trình phát triển phần mềm hướng đối tượng với 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, khối lượng công việc để thu được đặc tả thiết kế lớp hoàn chỉnh là rất lớn do sự bùng nổ số lượng lớp và các đặc trưng của chúng, cùng với sự phức tạp trong mối quan hệ giữa các lớp Ví dụ, một hệ thống đơn giản với 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ả, và con số này sẽ gia tăng sau mỗi phép biến đổi Việc thực hiện tiến trình này bằng tay sẽ rất khó khăn và dễ mắc sai sót, chỉ phù hợp cho các bài toán nhỏ Do đó, việc phát triển công cụ hỗ trợ cho tiến trình này là rất cần thiết và có ý nghĩa thiết thực.
Các nghiên cứu dưới đây là 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.
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, giú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 cho phép người dùng chỉ ra yêu cầu bằng cách vẽ biểu đồ với đồ 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 đúng đắn của hệ thống Bằng cách sử dụng công cụ, người dùng có thể chuyển đổi biểu đồ lớp khái niệm thành biểu đồ lớp thiết kế cuối cùng thông qua các thao tác như thêm lớp (bao gồm kế thừa), thêm thuộc tính, thêm phương thức, thay đổi đặc trưng của thuộc tính và phương thức, cũng như quản lý các mối quan hệ giữa các lớp.
Công cụ cần có khả năng quản lý tệp đặc tả hệ thống, bao gồm việc tạo mới, 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
Chức năng R.2.6 cho phép thay đổi đặc trưng của thuộc tính trong lớp được chọn, trong khi R.2.7 hỗ trợ việc điều chỉnh đặc trưng của phương thức trong lớp đó Ngoài ra, R.2.8 cung cấp khả năng xóa thuộc tính hoặc phương thức không cần thiết của lớp đã 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 MOF của OMG, các khái niệm UML được mô tả qua kiến trúc 4 lớp trừu tượng hóa: meta-metamodel, meta-metadata, metadata và data, trong đó 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 OMG sử dụng các ký pháp của chính mình để định nghĩa và tổ chức dữ liệu theo chuẩn MOF này.
Hệ thống của chúng ta chỉ liên quan đến các khái niệm thuộc biểu đồ lớp của UML, do đó, 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 sẽ có một tập các thuộc tính (Property) và một tập các 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
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 đưa ra cảnh báo hoặc ngăn chặn các thao tác không hợp lệ Mặc dù thao tác xóa các thành phần đặc tả hệ thống như lớp, phương thức và thuộc tính không thuộc về quy trình làm mịn, nhưng công cụ cũng nên hỗ trợ chức năng này để giúp người dùng sửa chữa các lỗi phát sinh 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 như 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, đồng thời lưu trữ các thay đổi vào lớp thực thể System Specification bằng cách 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 đồ Phương thức này gọi đến các phương thức Draw() của từng thành phần trong biểu đồ Mẫu thiết kế FactoryMethod được áp dụng để tổng quát hóa quá trình vẽ các thành phần của biểu đồ.
Phương thức SaveToFile() được thêm vào lớp MetaClass để lưu biểu đồ lớp thành các file, trong khi phương thức static LoadToFile() cho phép mở biểu đồ từ file XML đã lưu Để đơn giản hóa việc quản lý menu lệnh và thanh công cụ, đồng thời hỗ trợ chức năng Undo – Redo, 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 + ChangeVisibility (string newVisibility) : 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 III.3.2.1 Yêu cầu
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ả này 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 file ngoài nhằm thuận lợi cho việc lưu trữ và trao đổi Hơn nữa, cần chú ý đến các 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ó sự tương đồng trong cách định nghĩa với UML Do đó, chúng ta có thể sử dụng XML để 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, nó phải đáp ứng các yêu cầu về định dạng và ngữ nghĩa Theo W3C, để xác định cấu trúc, nội dung và ngữ nghĩa của tài liệu XML, có thể sử dụng DTD hoặc XML schema XML schema, là một tài liệu XML, có chức năng mô tả tài liệu XML khác và đượ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 từ lược đồ XML sẽ được xem là tài liệu XML hợp lệ.
XMI (XML Metadata Interchange) là một chuẩn của OMG được sử dụng để trao đổi thông tin siêu dữ liệu qua XML Chuẩn này phù hợp với các siêu dữ liệu mà mô hình của nó có thể được biểu diễn bằng Meta-Object Facility (MOF) XMI thường được áp dụng làm chuẩn trao đổi thông tin cho các mô hình UML và để tuần tự hóa (serialize) các đối tượng thành dãy bit hoặc ký tự.
Tư tưởng thiết kế của OMG 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, chẳng hạn như UML và SysML.
Mục đích chính 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 UML, đồng thời hỗ trợ các kho dữ liệu chuẩn MOF trong 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, allowing them to exchange data seamlessly through XMI files.
III.3.2.3 Lựa chọn phương án
Để quản lý file đặc tả chứa thông tin hệ thống và ký pháp đồ họa UML, tôi đã quyết định lưu trữ và đọc thông tin toàn bộ đặc tả trong một file duy nhất Các thao tác này được thực hiện thông qua tuần tự hóa và khôi phục đối tượng, cho phép lưu và phục hồi thông tin Công cụ FM Tool được phát triển để trao đổi dữ liệu đặc tả với các công cụ CASE khác, sử dụng chuẩn XMI FM Tool có khả năng xuất thông tin đặc tả ra file XML theo chuẩn XMI, giúp các công cụ khác đọc và khôi phục toàn bộ thông tin hệ thống, từ đó hỗ trợ 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 đặc tả mô hình dưới dạng file định dạng riêng, đồng thời hỗ trợ chức năng nhập/xuất (import/export) 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 chuẩn mực 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ụ
Việc phát triển công cụ FM Tool tuân theo quy trình RUP, sử dụng công cụ CASE Rational Rose Các sản phẩm từ các giai đoạn phân tích và thiết kế đã được trình bày ở phần trước.
Trong quá trình lập trình, nhằm thử nghiệm và đáp ứng nhu cầu 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 theo các bước đã nêu, từ đó xây dựng thành công công cụ FM Tool (hình 17) với các chức năng được mô 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 ra đị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:
Để thêm các thành phần như lớp và 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.
Để thay đổi vị trí và kích thước của các ký pháp đồ họa trong FM Tool, người dùng chỉ cần 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 attributes of a layer by right-clicking on the desired element and selecting "Properties" from the popup menu This action will display the modification form for 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 trong lớp, chúng tôi quy định rằng thuộc tính private được ký hiệu bằng dấu trừ (-), thuộc tính protected bằng dấu thăng (#), và thuộc tính public bằng dấu cộng (+) đứng trước thuộc tính hoặc phương thức tương ứng.
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, dưới sự hướng dẫn của 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, cho phép tạo nhóm, 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 thực hiện 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ác thao tác vi phạm luật làm mịn, công cụ sẽ thông báo và không cho phép thực hiện Mục đích của case study này là thử nghiệm các 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.
III.5.1 Khởi tạo hệ thống
Dựa trên tiến trình RUP, khi phân tích bài toán từ mô hình nghiệp vụ, chúng ta xây dựng mô hình khái niệm miền lĩnh vực, từ đó hình thành hệ thống khởi tạo ban đầu 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, nhận thấy rằng hai lớp Teacher và Student có chung thuộc tính name và phương thức PrinInfo() Do đó, để tối ưu hóa và tổng quát hóa, chúng ta có thể sử dụng danh từ “Person” để đại diện cho cả hai lớp này Vì vậy, lớp Person được thêm vào hệ thống, và các quan hệ tổng quát hóa từ lớp Teacher và Student đến lớp Person được thiết lập Đồng thời, thuộc tính name của hai lớp Teacher và Student sẽ được chuyển lên lớp cha Person.
Việc 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ả là chúng ta thu được đặc tả hệ thống APP 3, được tối ưu hóa từ APP 2, với 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 nhằm hiện thực hóa phần mềm hướng đối tượng theo phương pháp hình thức, với các chức năng cơ bản có thể sử dụng thực tế Công cụ này cho phép tạo ra đặc tả thiết kế hệ thống dưới dạng XML, gần gũi với mô hình lớp thiết kế của 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ác công cụ như Rational Rose Quá 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, chưa bao gồm nhiều phép biến đổi phức tạp và tinh tế khác 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 để bổ sung vào công cụ Đồng thời, chúng tôi cũng sẽ 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, giúp người 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#.