Luận văn thạc sĩ VNU UET 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 công việc: phân tích, thiết kế và lập trình hướng đối tượng Phương pháp này dựa trê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à hoạt động điều tra, nghiên cứu hệ thống nhằm tìm hiểu kỹ bài toán, tìm ra các đối tượng để xây dựng các module của hệ thống phần mềm, phân tách bài toán thành các phần nhỏ hơn, xây dựng mô hình logic mô tả chức năng của toàn hệ thống

Nhiệm vụ của thiết kế hướng đối tượng (OOD) là 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, xây dựng mô hình kiến trúc và mô hình tính toán cho hệ thống Kiến trúc trong OOD nhấn mạnh đến việc định nghĩa các đối tượng phần mềm và tương tác giữa chúng

Lập trình hướng đối tượng (OOP) cho phép chúng ta kết hợp những tri thức bao quát về các quá trình với các khái niệm trừu tượng được sử dụng trong máy tính Cụ thể hơn nhiệm vụ giai đoạn này là chuyển các đặc tả hệ thống đối tượng từ bản thiết kế thành chương trình mã máy bằng các công cụ và ngôn ngữ lập trình hướng đối tượng.

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

Các phương pháp hướng đối tượng nói chung và lập trình hướng đối tượng nói riêng cho phép chúng ta giải quyết được nhiều vấn đề gây khó khăn, trở ngại cho quá trình phát triển phần mềm Ngoài những khía cạnh đã phân tích ở trên, những ưu điểm chính của phương pháp hướng đối tượng là:

- Giúp cho nhà phát triển có tư duy ánh xạ các đối tượng bài toán vào phần mềm, nhờ đó hệ thống trở nên trong sáng dễ hiểu và gần gũi với người dùng

- Những đối tượng được thiết kế tốt trong những hệ thống hướng đối tượng là cơ sở để kết hợp các đơn thể được sử dụng lại thành hệ lớn hơn, tạo ra những hệ

- 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 đảm bảo cho việc mô tả các giao diện giữa các đơn thể bên trong hệ thống và các hệ thống bên ngoài trở nên dễ dàng hơn Điều đó cũng đảm bảo cho việc phân chia công việc trong dự án có cơ sở tự nhiên và dễ hiểu hơn

- Nguyên lý che dấu thông tin hỗ trợ cho việc xây dựng các hệ thống thông tin an toàn Nguyên lý thiết kế dựa chính vào dữ liệu rất phù hợp với ngữ nghĩa của mô hình trong cài đặt

- Đị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

Một tiến trình phát triển phần mềm là một tập các hoạt động cần thiết để chuyển yêu cầu người sử dụng thành một hệ thống phần mềm đáp ứng được các yêu cầu đặt ra [6](hình 1)

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à tiến trình phát triển phần mềm do Rational Software phát triển và bảo trì Đó là một khung làm việc chung mà có thể được chuyên biệt hoá cho mỗi lớp lớn của các hệ thống phần mềm, cho các lĩnh vực ứng dụng khác nhau, các kiểu tổ chức khác nhau, các cấp độ hoàn thiện khác nhau và các qui mô dự án khác nhau

Tiến trình thống nhất dựa trên các thành phần, điều đó có nghĩa là hệ thống phần mềm được xây dựng dựa trên các thành phần phần mềm kết nối với nhau thông qua giao diện đã được định nghĩa trước

Tiến trình thống nhất sử dụng ngôn ngữ mô hình hoá thống nhất UML để thiết kế các hệ thống phần mềm RUP giúp sử dụng hiệu quả UML và trên thực tế UML là một phần tích hợp của 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 tạo ra là để phục vụ người dùng, thuật ngữ người dùng ở đây bao gồm cả người dùng hệ thống hay các hệ thống khác tương tác sử dụng dịch vụ hệ thống mà chúng ta xây dựng

Một ca sử dụng (use case) là một phần chức năng hệ thống cung cấp cho người dùng để đem lại kết quả nào đó khi sử dụng nó Các ca sử dụng dùng để nắm bắt các yêu cầu chức năng Tập hợp tất cả các ca sử dụng lập thành mô hình ca sử dụng mô tả đầy đủ chức năng của hệ thống (hình 2) Mô hình này sẽ thay thế cho các đặc tả chức năng hệ thống bằng phương pháp truyền thống Một đặc tả chức năng thường trả lời câu hỏi: hệ thống được dự kiến sẽ là gì? Nhưng đối với ca sử dụng thì câu hỏi lại là: hệ thống dự kiến sẽ làm được gì cho mỗi người sử dụng?

Ca sử dụng không phải chỉ là một công cụ để đặc tả các yêu cầu của hệ thống, nó còn điều khiển các tiến trình thiết kế, cài đặt và kiểm thử theo ngữ nghĩa như sau:

Trước hết ca sử dụng phản ánh yêu cầu của hệ thống cần phải thực hiện để đem lại dịch vụ cho những người sử dụng và kết quả là những giá trị gia tăng mà họ nhận được Dựa trên mô hình ca sử dụng, người phát triển tạo ra một loạt các mô hình phân tích, thiết kế và cài đặt nhằm vào việc ca sử dụng ở những mức khác nhau (từ mức khái niệm đến mức logic và phương tiện vật lý) và xem xét để sao cho mỗi mô hình này phù hợp với việc thực hiện mô hình ca sử dụng xây dựng được

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

Những người kiểm tra sẽ kiểm tra 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 cài đặt đúng các ca sử dụng Do vậy, ta nói rằng ca sử dụng điều khiển quá trình phát triển, điều đó có nghĩa là quá trình phát triển tuân theo các luồng công việc được điều khiển 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

Vai trò của kiến trúc hệ thống phần mềm giống như khung nền, dựa trên đó phần mềm được xây dựng và phát triển đến hoàn thiện Khái niệm kiến trúc phần mềm chứa đựng các khía cạnh tĩnh và động có ý nghĩa nhất đối với hệ thống Nó được phát triển dựa theo yêu cầu của tổ chức, theo cảm nhận của người dùng và các tổ chức có - liên quan khác được phản ánh qua các ca sử dụng Mặt khác, nó cũng chịu ảnh hưởng của rất nhiều nhân tố, chẳng hạn như môi trường nền của hệ thống, các khối xây dựng dùng lại có sẵn, các điều cân nhắc triển khai và các yêu cầu phi chức năng (như tính thể hiện, độ tin cậy ) Kiến trúc là một khung nhìn thiết kế tổng thể về những đặc điểm quan trọng nhất của hệ thống và tạm bỏ qua các chi tiết

Vậy ca sử dụng và kiến trúc có quan hệ với nhau như thế nào? 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 phải cân bằng với nhau để đem lại kết quả tốt nhất Chức năng tương ứng với các ca sử dụng và hình thức thể hiện tương ứng với kiến trúc Do đó việc lựa chọn các ca sử dụng để phát triển được định hướng theo kiến trúc và phù hợp với kiến trúc Nói cách khác, kiến trúc phải cung cấp chỗ dựa cho việc thực hiện các ca sử dụng ngay từ khi bắt đầu tiến trình hệ thống và cả trong tương lai Trên thực tế, cả kiến trúc và ca sử dụng đều phát triển song song

Kiến trúc của hệ thống là thành phần quan trọng nhất, được sử dụng để quản lý các khung nhìn khác, để điều khiển phát triển hệ thống tăng dần và lặp lại trong suốt chu kỳ sống của hệ thống phần mềm Kiến trúc là tập các quyết định về:

- 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 của hệ thống phần mềm chuyên sâu được mô tả bằng các khung nhìn tương tác với nhau (hình 3) Các khung nhìn ánh xạ vào tổ chức và cấu trúc hệ thống, mỗi khung nhìn tập trung vào một khía cạnh cụ thể 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

Việc phát triển một phần mềm nói chung đòi hỏi một số lớn công việc và có thể diễn ra trong một khoảng thời gian nhất định Việc chia nhỏ toàn bộ công việc thành các phần nhỏ hoặc các dự án con là yêu cầu thiết thực Mỗi dự án con là một bước lặp và tạo nên một sự tăng trưởng Điều này dễ dàng thực hiện được khi phát triển phần mềm hướng đối tượng, vì nó được cấu thành từ các thành phần độc lập ghép nối lại với nhau Để đạt hiệu quả nhất, các bước lặp phải được điều khiển, nghĩa là chúng phải được lựa chọn và tiến hành theo kế hoạch đã được định trước

Lựa chọn gì cần để cài đặt trong một bước lặp dựa trên hai yếu tố sau: Thứ nhất, bước lặp phải liên quan tới một nhóm các ca sử dụng để mở rộng tính khả dụng của hệ thống khi phát triển Thứ hai, bước lặp phải giải quyết những rủi ro quan trọng nhất

Mỗi bước lặp tiếp được xây dựng trên cơ sở các chế tác từ trạng thái mà nó vừa kết thúc ở bước lặp trước [21] Bởi vì là một dự án con, nên từ các ca sử dụng đã sử dụng, nó tiếp tục thực hiện các công việc phân tích, thiết kế, cài đặt và kiểm thử đối với các chức năng còn lại được nắm bắt trong các ca sử dụng tiếp theo để đưa chúng về dạng các mã nguồn thực thi được Tuy nhiên, trong một vài bước đầu, người phát triển có thể chỉ thay thế một thiết kế còn sơ bộ bằng một thiết kế khác chi tiết hơn, phức tạp hơn, vì vậy có thể chưa tạo ra sự tăng trưởng của sản phẩm Nhưng ở các bước sau, sự tăng trưởng của sản phẩm nói chung là tất nhiên và cần thiết

Trong mỗi bước lặp, người thiết kế xác định các ca sử dụng liên quan, tạo lập thiết kế dựa trên kiến trúc đã chọn, triển khai thiết kế dưới dạng các thành phần, kiểm tra mức độ tương ứng giữa các thành phần và các ca sử dụng Nếu một bước lặp thoả mãn được các mục đích của nó thì có thể chuyển sang bước lặp tiếp theo Nếu không, người thiết kế phải xem lại các quyết định trước đây của mình và thử một cách tiếp cận mới

Một dự án gọi là thành công nếu được tiến hành mà không chệch hướng nhiều so với kế hoạch đã định ra Tối thiểu hoá được các vấn đề còn chưa được nhận thức, đó chính là mục tiêu của việc giảm rủi ro.

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 được chia thành 4 pha [17] (hình 4): sơ bộ (inception), chi tiết (elaboration), xây dựng (construction), và chuyển giao (transition)

Trong mỗi pha lại chia thành nhiều bước lặp nhỏ (phase), mỗi bước lặp gồm một số công việc thực hiện trọn vẹn một sản phẩm phần mềm (product release): 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, bước lặp trong mỗi pha khác với bước lặp ở các pha khác về nội dung cũng như khối lượng công việc thực hiện (hình 5)

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à tiến trình dựa trên thành phần Nó sử dụng mô hình hoá trực quan mới nhất – ngôn ngữ mô hình hoá thống nhất UML và dựa trên ba ý tưởng chính sau: ca sử dụng, kiến trúc, phát triển lặp và tăng dần Để làm được điều này, khi thực hiện tiến trình cần phải xem xét đến nhiều mặt, đó là: các vòng đời, các giai đoạn, các dòng công việc, giảm độ rủi ro, kiểm soát chất lượng, quản lý dự án, quản lý cấu hình Tiến trình thống nhất chính là một khung làm việc mà đã tích hợp được tất cả các mặt này Nó cho phép những nhà xây dựng công cụ và người phát triển có thể xây dựng nên các công cụ hỗ trợ cho việc tự động hoá quá trình, hỗ trợ các dòng công việc cụ thể, xây dựng nên các mô hình khác nhau, tích hợp công việc qua vòng đời và qua các mô hình[18].

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:

- Đặc tả yêu cầu: Việc áp dụng phương pháp hình thức với các ngôn ngữ mang tính toán học chính xác sẽ làm cho yêu cầu của khách hàng được rõ ràng, loại bỏ những điều nhập nhằng, không nhất quán không đầy đủ

- Thiết kế hệ thống: Các ngôn ngữ hình thức cung cấp cho các nhà thiết kế một ngôn ngữ để đặc tả cấu trúc hệ thống, đặc tả mối quan hệ các thành phần, làm mịn từng bước cho hệ thống

- Xác minh: Nhờ các công cụ toán học được cung cấp trong ngôn ngũ hình thức, chúng ta có thể chứng minh tính đúng đắn của hệ thống, đảm bảo hệ thống thỏa mãn các yêu cầu đặc tả

- Thẩm định: Nhà phát triển và khách hàng dựa vào đặc tả và sản phẩm để thẩm định xem liệu sản phẩm có thỏa mãn yêu cầu không? Ngoài ra ngôn ngữ hình thức còn giúp ích cho công 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:

- Có khả năng làm tăng chất lượng và năng suất phần mềm: vì ngôn ngữ hình thức làm tăng khả năng hiểu chính xác hệ thống, sớm phát hiện ra các lỗi (có thể ngay từ giai đoạn đặc tả), cho phép mô hình hóa một cách hình thức và phân tích trực tiếp trên mô hình, cho phép giả lập, thực thi, chứng minh trên 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

- Giảm giá thành: do phương pháp hình thức giúp phát hiện lỗi sớm (ngay từ các giai đoạn đầu như đặc tả yêu cầu, phân tích, thiết kế) do đó giảm chi phí sửa đổi phần mềm.

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

Một ngôn ngữ đặc tả hình thức bao gồm: cú pháp và ngữ nghĩa Một ngôn ngữ đặc tả hình thức phải có các tính chất: không nhập nhằng, nhất quán, đầy đủ và có thể 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

Từ những trình bày ở trên, có thể thấy rằng 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 là hai hướng tiếp cận quan trọng trong nghành công nghệ phần mềm Tuy nhiên chúng vẫn có những khoảng cách nhất định và khá độc lập với nhau Từ thực tế này mục tiêu đặt ra của đề tài là nghiên cứu các ngôn ngữ hình thức, lựa chọn và áp dụng một ngôn ngữ vào tiến 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 thử nghiệm một công cụ trợ giúp cho việc đặc tả hình thức hóa hệ thống phần mềm hướng đối tượng

Hướng tiếp cận được thực hiện trong đề tài này là tiến hành đặc tả hệ thống hướng đối tượng theo ngôn ngữ rCOS, sau đó bằng một loạt các phép biến đổi đại số và các luật đã được chứng minh đưa đặc tả hệ thống thành thiết kế cuối cùng Do hệ thống được đặc tả bao gồm các khái niệm rất gần gũi với khái niệm về biểu đồ lớp thiết kế của mô hình UML, nên dễ dàng chuyền nó sang dạng biểu diễn của biểu đồ thiết kế trong UML, từ đó có thể sinh được mã lệnh chương trình của một ngôn ngữ lập trình hướng đối tượng bằng công cụ sẵn có, ví dụ như Rational Rose, 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) [9], [15] là một mô hình ngữ nghĩa quan hệ và phép làm mịn cho 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 rCOS được phát triển bởi He Jifeng, Zhiming Liu và Xiaoshan Li tại UNU-IIST Cơ sở của rCOS dựa trên lý thuyết lập trình thống nhất (UTP) của Hoare và He rCOS hỗ trợ cho việc phân tích và mô hình hóa cả phần mềm dựa trên trạng thái và cả 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 bằng logic vị từ và đại số quan hệ Mọi chương trình được xem như là mối quan hệ nhị phân giữa lệnh và trạng thái của các biến, các lệnh được thi hành trong chương trình và tác động lên trạng thái chương trình Trong UTP [16], Hoare and He đề xuất một mô hình dựa trên trạng thái trong đó mô tả một lệnh hay một bước chuyển bởi bộ (α, P) trong đó:

- α là tập các biến của chương trình hay còn gọi là bảng chữ cái, α được chia thành 3 nhóm: o Nhóm thứ nhất là các biến toàn cục và cục bộ: ký hiệu alphabet biểu diễn tập các biến toàn cục trong chương trình: {x 1 : T 1 , x 2 :T 2 ,… x n :T n } với Ti là kiểu của biến x i :

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

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 quan hệ giữa các giá trị ban đầu của các biến và các giá trị kết quả của nó Pre ⊢ Post, hoặc cụ thể hơn p(x) ⊢ R(x,x’) với định nghĩa: p(x) ⊢ R(x, x’) = def ok ∧ p(x) ⇒ ok’ ∧ R(x, x’) Trong đó: o p(x) được gọi là tiền điều kiện và phải có giá trị true – tức là đúng đắn trước khi chương trình bắt đầu o R(x, x’) gọi là hậu điều kiện nhận được sau khi chương trình thực hiện x và x’ biểu diễn giá trị khởi đầu và kết thúc của biến x trong chương trình o 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 thức ok là true, nếu việc thực hiện chương trình cuối cùng thành công ok’ là true, ngược lại chúng 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ể có kiểu là kiểu con mà nó được khai báo Điều này thực chất thể hiện tính đa hình của hệ thống hướng đối tượng

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

Một hệ thống đối tượng được cấu thành từ tập các khai báo lớp và lệnh có dạng cdecls ● Main Trong đó cdecls biểu diễn phần khai báo các lớp và xác định các dịch vụ được cung cấp bởi các đối tượng, main là cặp (externalvar, c) được dùng để mô tả hành vi các đối tượng và đóng vai trò phương thức main trong các ngôn ngữ như Java, 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 có thể được khai báo private hoặc là public, ngầm định là public Chỉ các lớp có kiểu public hoặc kiểu cơ sở mới đượ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 khai báo các thuộc tính private của lớp, bao gồm kiểu và các giá trị khởi tạo Tương tự, các phần protected và public khai báo các thuộc tính protected và public của lớp

- Phần method khai báo các phương thức của lớp N, trong đó m 1 , m 2 , , m ℓ là các phương thức, ở đây (T i1 x i1 ), (T i2 y i2 ), (T i3 z i3 ) và c i biểu diễn các tham số giá trị, tham số kết quả, các tham số giá trị - kết quả và phần thân của phương thức m i Phương thức có thể được chỉ ra bởi biểu diễn m(paras){c}, trong đó paras là các tham số và c là thân lệnh của m Để cho gọn có thể ký hiệu N[parent, pri, pro, pub, op] biểu diễn một lớp trong đó N là tên của lớp, parent có dạng một tập các lớp cha (có thể rỗng nếu N không có lớp cha), pri, pro, pub biểu diễn tập các thuộc tính private, protected và public, op là tập các phương thức của lớp N Trong các phần sau, các ký hiệu tương ứng parent(N), pri(N), prot(N), pub(N), op(N) cũng có ý nghĩa tương tự và được dùng để chỉ các ký hiệu đó gắn với lớp N

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

Biểu thức trong ngôn ngữ hướng đối tượng có thể xuất hiện vế bên phải của các lệnh gán, xác định theo các qui tắc như sau [16]: e ::= x | null | self | e.a | e is C | C(e) | f(e)

Trong đó x là biến đơn, null là kiểu đối tượng đặc biệt, lớp đặc biệt NULL là lớp con của mọi lớp và null là duy nhất, self được sử dụng để chỉ đối tượng hoạt động trong phạm vi hiện tại, e.a là thuộc tính a của e, e is C là kiểu kiểm thử (test), C(e) là

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 xác định đúng khi le và e đã được xác định đúng và kiểu của e là kiểu con của kiểu đã được khai báo le Trong trường hợp lệnh gán đơn x := e , khi lệnh gán được xác định đúng nó chỉ thay đổi x bởi gán x bằng giá trị của e Trong trường hợp sự thay đổi thuộc tính của đối tượng, le.a := e thay 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

Nhìn lại tiến trình RUP ta thấy, RUP đã sử dụng một số mô hình khác nhau của UML để phát triển phần mềm hướng đối tướng Đó là 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à biểu đồ trạng thái, và mô hình thiết kế với biểu đồ lớp thiết kế Việc sử dụng nhiều khung nhìn cho viêc mô hình hoá hệ thống đã làm trực quan hóa quá trình phát triển và có thể quản lý chúng theo những cách riêng Tuy nhiên, việc dùng nhiều mô hình để phát triển hệ thống phải đối mặt với các khó khăn về sự khác nhau của nhiều khung nhìn ở những thời điểm khác nhau của tiến trình phát triển Đặc biệt, tính nhất quán giữa các mô hình cùng loại trong một pha và giữa các loại mô hình khác nhau của các pha khác nhau không có gì đảm bảo chắc chắn Một số vấn đề dưới đây đã được các nghiên cứu [7], [10], [23] đề xuất giải pháp:

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

Những giải pháp trên đây hoặc mới giải quyết sự đồng bộ và nhất quán trên một khung nhìn (hai giải pháp đầu) hoặc tạo ra cơ chế cho phép kiểm soát sự đồng bộ và nhất quát, tức là mới nhằm hạn chế được sự thiếu nhất quán và đồng bộ của hệ thống

Nhận xét về RUP ta thấy RUP bắt đầu với khung nhìn nghiệp vụ có chứa mô hình lớp khái niệm và khi kết thúc tiến trình trước khi chuyển sang mã nguồn, chúng ta lại thu được biểu đồ lớp thiết kế của hệ thống phần mềm Nếu ta chỉ sử dụng một khung nhìn duy nhất được biểu diễn bằng các biểu đồ lớp, ta sẽ khắc phục được tính đa khung nhìn của RUP Để khắc phục những nhược điểm còn tồn tại ở trên, tiến trình phát triển mới [1] chỉ dựa trên một khung nhìn (mô hình) duy nhất được biểu diễn bằng các biểu đồ lớp để phát triển hệ thống từ hệ khởi thảo cho đến hệ thống kết quả cuối cùng (hình

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

Vấn đề là làm sao xây dựng được các phép biến đổi và các quy tắc kiểm tra sự đúng đắn của chúng, khi đó bằng một loạt các phép biến đổi đúng đắn ta sẽ chuyển biểu đồ lớp khái niệm băn đầu về biểu đồ lớp thiết kế cuối cùng của 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ác công cụ trợ giúp cho việc xác định các phép biến đổi nào được sử dụng

Qua sơ đồ ta thấy, để đạt đến biểu đồ lớp thiết kế cuối cùng, chúng ta cần đến các phép biến đổi sau: thêm lớp (có thể là kế thừa) vào hệ thống, thêm thuộc tính, thêm phương thức cho một lớp của hệ thống, thay đổi đặc trưng của thuộc tính, của phương thức hay thay đổi liên kết giữa các lớp và các biến đổi tương ứng trong mỗi phương thức của lớp trong hệ thống Hơn nữa, mỗi hệ thống nhận được ở bước sau phải nhất quán và đồng bộ với bước trước Để đạt được điều này, ở đây cần giải quyết hai vấn đề:

- 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à

[3] Việc chứng kiểm chứng tính đúng đắn của các phép biến đổi hoàn toàn có thể được thực hiện bằng việc áp dụng các phương pháp hình thức như rCOS Thao tác kiểm chứng tính đúng đắn của các phép biến đổi được thực hiện qua hai phạm vi: tính đúng đắn trong một mô hình (kiểm chứng tĩnh) và tính phù hợp của đặc tả hệ thống trong hai bước biến đổi liên tiếp (kiểm chứng động) Do vậy hệ thống đặc cuối cùng thu được sẽ hoàn toàn đúng đắ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 còn gọi là mô hình khái niệm thô Đó chính là mô hình miền lĩnh vực, mô tả các khái niệm quan trọng của hệ thống qua các đối tượng của lĩnh vực nghiệp vụ và các liên kết giữa chúng với nhau Bước này tương ứng với bước phát triển mô hình nghiệp vụ hệ thống trong RUP vì vậy có thể sử dụng RUP để hỗ trợ tìm ra các lớp khái niệm nhờ 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, cụ thể là bổ sung tên các lớp N i đặc trưng cho các đối tượng miền lĩnh vực vào biểu đồ lớp của mô hình hệ thống có dạng APP 0 = N 1 []; N 2 []; ; N k [] và xác định những quan hệ giữa các lớp khái niệm Ni Phép biến đổi này được thực hiện bằng thuật toán addClassName như sau:

// 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)

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 có được đặc tả hệ thống ban đầu APP 0 sau bước xây dựng hệ thống khởi tạo, nhà phát triển thực hiện liên tiếp n bước làm mịn để thu được đặc tả hệ thống lớp thiết kế cuối cùng APP n

Sau đây là một trình tự các bước làm mịn chính, tuy nhiên có thể áp dụng mềm dẻo các bước này để thu được một đặc tả đầy đủ và chính xác Các bước a, b, c đã được trình bày và chứng minh trong nghiên cứu [15], các luật làm mịn trong phần a, b và c là các luật khá cơ bản và thường gặp Trong luận văn này tác giả đề xuất luật làm mịn thêm các quan hệ giữa các lớp và các ràng buộc của luật này (phần d) a) Bổ sung các thuộc tính cho lớp

Khi đã có một lớp, ta cần xác định và bổ sung các thuộc tính private và định dạng các kiểu cho nó (khi không giả thiết gì, thuộc tính trong lớp mặc định là private)

Việc thêm một thuộc tính thành phần vào một lớp có thể được thực hiện theo luật bổ sung sau:

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

//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

Kết chương

Tiến trình phát triển RUP là tiến trình rất nổi tiếng và phổ biến dùng để phát triển phần mềm hướng đối tượng Tuy nhiên, nhà phát triển sử dụng nó phải đối mặt một vài vấn đề về đảm bảo tính nhất quán các mô hình, khả năng tích hợp các khung nhìn Á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 là một hướng giải quyết vấn đề

Mô hình quan hệ ngữ nghĩa của rCOS có thể được dùng để đặc tả hệt thống hướng đối tượng và chứng minh các luật làm mịn Tiến hành các bước biến đổi làm mịn hệ thống theo các luật làm mịn của rCOS sẽ luôn đảm bảo tính đúng đắn của hệ thống do các bước làm mịn đã được kiểm chứng bởi các luật 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 ở hai 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 đã trình bày các nghiên cứu về 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 thì khối lượng công việc cần thực hiện để thu được đặc tả thiết kế lớp hoàn chỉnh là khá lớn do sự bùng nổ của số lượng lớp cùng các đặc trưng của nó (thuộc tính, phương thức) và đặc biệt có sự phức tạp của các mối quan hệ giữa chúng Nếu ta hình dung rằng, một hệ thống đối tượng khởi tạo đơn giản với 5 lớp, mỗi lớp có 5 thuộc tính và 5 phương thức, mỗi phương thức có 3 tham biến, giữa các cặp lớp có trung bình 1 mối quan hệ, thì chúng ta cần đến ít nhất (5tênlớp +5x(5biến+5phươngthức x 3tham số) + (4quanhệ x 2tênlớp) = 113 biến để đặc tả hệ thống Con số này sẽ tăng lên không ngừng sau mỗi phép biến đổi Cho nên, nếu thực hiện tiến trình phát triển trên đây bằng tay, thì đó sẽ là một công việc cực nhọc, chưa kể rất dễ mắc sai sót, và cũng chỉ có thể giải quyết được các bài toán nhỏ Vì vậy, nhu cầu tạo công cụ để trợ giúp tiến trình phát triển này là một yêu cầu cấp bách và có ý nghĩa thiết thực [3]

Những nghiên cứu dưới đây là những kết quả bước đầu của việc phát triển cộng cụ trợ giúp sự tự động hóa tiến trình phát triển hệ thống hướng đối tượng đã nêu trên.

Phân tích hệ thống

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

Công cụ này trợ giúp quá trình phát triển phần mềm hướng đối tượng dựa trên một khung nhìn duy nhất – khung nhìn biểu đồ lớp Vì thế, công cụ cần trợ 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 đồ lớp, công cụ cần phải có một giao diện người dùng trực quan với các ký pháp UML Người dùng chỉ cần chỉ ra các yêu cầu cần thiết bằng cách vẽ biểu đồ với các ký pháp đồ họa chuẩn, khi đó công cụ sẽ tiến hành các phép biến đổi phía trong theo đúng các luật và ràng buộc đặt ra để đảm báo tính đúng đắn của hệ thống đặc tả nhận được Sử dụng công cụ thực hiện một loạt các phép biến đổi, người dùng có thể chuyển biểu đồ lớp khái niệm ban đầu về biểu đồ lớp thiết kế cuối cùng Các thao tác cơ bản mà công cụ cần hỗ trợ bao gồm: thêm lớp (có thể kế thừa), thêm thuộc tính, thêm phương thức vào một lớp, thay đổi các đặc trưng của thuộc tính, của phương thức, thêm và thay đổi các mối quan hệ giữa các lớp

Ngoài ra, công cụ cần có khả năng quản lý các tệp đặc tả hệ thống, bao gồm: tạo mới một hệ thống hay mở tệp của một hệ thống đã có hay lưu chúng vào tệp để sử dụng sau này Ta có thể mô tả các chức năng của công cụ 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

Phần này ta xét các thành phần khái niệm có trong công cụ của chúng ta Theo chuẩn đặc tả MOF của OMG [26], [27] các khái niệm của UML được mô tả bằng kiến trúc 4 lớp trừu tượng hóa: meta-metamodel, meta-metadata, metadata, data (là lớp cuối cùng người dùng UML vẫn dùng để mô hình hóa các hệ thống) Theo chuẩn MOF này, OMG dùng chính các ký pháp của OMG để mô tả, định nghĩa, tổ chức dữ liệu

Do 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 nên ở đây ta chỉ tập trung vào đặc tả kiến trúc thượng tầng [27] của biểu đồ lớp (hình 9) Các lớp khái niệm trong hệ thống này sẽ được lấy tên tương tự trong biểu đồ hình 9 Một đặc tả hệ thống (MetaClass) chứa 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 một lớp có một tập các thuộc tính (Property) và tập các phương thức (Operation) (hình 10)

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

LUAN VAN CHAT LUONG download : add luanvanchat@agmail.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

Tại các ca sử dụng đặc tả làm mịn hệ thống, công cụ phải kiểm tra các ràng buộc (được nêu ra trong các luật làm mịn ở phần II.2.2) sau mỗi thao tác người dùng và đưa ra cảnh báo hoặc ngăn cấm các thao tác không hợp lệ Tuy các thao tác xóa các thành phần đặc tả hệ thống (lớp, phương thức, thuộc tính) không phải là các thao tác làm mịn hệ thống nhưng ở đây công cụ cũng nên hỗ trợ vì nó giúp cho người dùng sửa được các 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 qua các lớp giao diện (Management Boundary, Operation Boundary) để tạo mới, mở, lưu và thực hiện các thao tác làm mịn biểu đồ Các lớp điều khiển Management Control và Operation control trợ giúp người dùng thực hiện các thao tác trên giao diện người dùng và tiến hành các tác vụ biến đổi bên trong hệ thống đặc tả và lưu các thay đổi này vào lớp thực thể System Specification khi sử dụng các nhân tố từ UML Element và File Management Object (hình 12)

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 đó ta thêm các thuộc tính và phương thức cho các lớp thiết kế Để phục vụ cho việc thể hiện trực quan biểu đồ, lớp MetaClass có phương thức Draw() để vẽ toàn bộ biểu đồ bằng cách gọi phương thức Draw() của các thành phần trong biểu đồ Mẫu thiết kế FactoryMethod [11] được dùng tổng quát hóa công việc vẽ các thành phần biểu đồ

Nhằm lưu biểu đồ lớp thành các file, phương thức SaveToFile() được thêm vào lớp MetaClass Ngược lại phương thức static LoadToFile() dùng để mở biểu đồ từ file XML đã lưu từ phiên làm việc trước Để đơn giản hóa việc quản lý menu lệnh, thanh công cụ của hệ thống và hỗ trợ chức năng Undo – Redo cho các thao tác chúng tôi sử dụng mẫu thiết kế Command

Các phương thức: MetaClass:AddClass, MetaClass:AddRelationship, Class:Rename, Class:ChangeVisibility, Class:AddProperty, Class:RemoveProperty, Class:AddOperation, Class:RemoveOperation, Property:ChangeVisibitlity, Operation: ChangeVisibility được thực hiện theo các thuật toán làm mịn mô hình lớp được nêu ở các phần trên (hình 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 trong những vấn đề cơ bản của việc xây dựng công cụ Cần có cơ chế cho việc biểu diễn, đọc và lưu các đặc tả hệ thống một cách thuận tiện, tức là làm sao để chuyển đặc tả hệ thống từ dạng các đối tượng trong bộ nhớ thành cấu trúc dữ liệu file ngoài để tiện cho việc lưu trữ, trao đổi

Ngoài ra, cũng cần quan tâm đến các chuẩn của các công cụ CASE hiện nay để có thể chuyển dữ liệu từ công cụ xây dựng sang các công cụ phổ biến hiện nay như Rational Rose, PowerDesinger…

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

Ngôn ngữ XML vốn là một ngôn ngữ được thiết nhằm mô tả dữ liệu, hơn nữa lại có sự tương đồng về cách định nghĩa XML và UML (hình 16) cho nên ta hoàn toàn có khả năng biểu diễn thông tin đặc tả của hệ thống hướng đối tượng bằng XML [25]

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

Một văn bản XML tuân thủ đúng cấu trúc cú pháp mới chỉ là văn bản XML đúng định dạng (well-formed XML document), để một văn bản XML tuân thủ theo cấu trúc mong muốn và mang những thông tin ngữ nghĩa cần thiết để tiện trong việc trao đổi thông tin thì văn bản XML đó cần phải hợp lệ tức là phải có định dạng và ngữ nghĩa theo ý muốn Theo W3C, để quy định cấu trúc, nội dung và ngữ nghĩa của một tài liệu XML có thể dùng DTD hoặc XML schema (lược đồ XML) XML schema bản thân nó cũng là một tài liệu XML nhưng mục đích nó là mô tả tài liệu XML khác do đó người ta gọi XML schema là một tài liệu siêu dữ liệu (dữ liệu mô tả dữ liệu) Một tài liệu XML đúng định dạng mà tuân thủ theo thông tin mô tả nó trong lược đồ XML thì gọi là tài liệu XML hợp lệ (validity XML document) b) Chuẩn XMI

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

Tư tưởng thiết kế đặc tả các mô hình của OMG là 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 biểu diễn thông tin ngữ nghĩa trong khi đó mô hình thực biểu diễn các biểu đồ trực quan Các mô hình trừu tượng là các thể hiện của các ngôn ngữ mô hình tùy ý dựa trên MOF như UML hay SysML

Một mục đích của XMI là cho phép chuyển đổi dễ dàng siêu dữ liệu giữa các công cụ mô hình hóa dựa trên UML, trên 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

Hiện nay các công cụ UML nổi tiếng trên thị trường đều hỗ trợ XMI do đó chúng có thể trao đổi dữ liệu với nhau qua các file XMI, có thể kể ra ở đây Rational Rose [17], PowerDesigner, Enterprise Architect…

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

Từ yêu cầu về quản lý file đặc tả chứa toàn bộ thông tin về đặc tả hệ thống và các ký pháp đồ họa UML nên tôi đã chọn phương án lưu và đọc thông tin toàn bộ đặc tả hệ thống bằng một file duy nhất Các thao tác lưu và đọc này được thực hiện bằng việc tuần tự hóa và khôi phục (tức là lưu một đối tượng thành file, file này có thể dùng để khôi phục lại thông tin đối tượng) Để công cụ được xây dựng, tạm đặt tên FM Tool có thể trao đổi dữ liệu đặc tả với các công cụ CASE khác hiện có thì chuẩn XMI được lựa chọn Theo đó, FM Tool có chức năng xuất thông tin đặc tả ra một file XML theo chuẩn XMI File này có thể được công cụ đọc và khôi phục lại toàn bộ thông tin về đặc tả hệ thống, từ đó có thể dùng các công cụ này để thực hiện một số thao tác khác như: tiếp tục biến đổi, làm tài liệu, sinh mã khung chuơng trình tự động…

Hiện nay các công cụ CASE nổi tiếng trên thị trường hầu hết đều làm theo cách này: lưu thông tin đặc tả mô hình thành một file định dạng riêng, bên cạnh đó có chức năng nhập/xuất (import/export) đặc tả từ các công cụ khác bằng XMI Do đó phương án được chúng tôi lựa chọn ở đây hoàn toàn tuân theo các chuẩn và xu hướng chung.

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 được tiến hành theo tiến trình RUP Công cụ CASE được sử dụng ở đây là Rational Rose Sản phẩm của các pha và các giai đoạn phân tích thiết kế đã được trình bày ở phần trên

Trong bước lập trình, với mục đích thử nghiệm và do nhu cầu về thời phát triển cần nhanh chúng chúng tôi đã chọn ngôn ngữ Visual C# chạy trên nền 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

Tiến hành quy trình theo các phần được trình bày ở trên, chúng tôi đã xây dựng thành công công cụ FM Tool (hình 17) có các chức năng theo mô tả ở phần III.2.1

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

Giao diện của FM Tool được thiết kế khá đơn giản và dễ sử dụng Menu và thanh công cụ đều rất quen thuộc với người dùng vì thế các thao tác tạo, lưu và mở tệp hệ thống được thực hiện 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 XMI cú thể chọn từ menu Fileặ Export to XMI hoặc ấn nút Export to XMI trên thanh công cụ b) Phát triển và làm mịn đặc tả hệ thống

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, quan hệ giữa các lớp vào đặc tả hệ thống, người dùng click vào thanh công cụ và vẽ các đối tượng tương ứng vào phần thể hiện ký pháp đồ họa

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

- Các thành phần, thuộc tính của lớp có thể được sửa đồi bằng cách click phải chuột vào thành phần đó và chọn Properties từ menu popup (hình 18), chương trình sẽ hiển thị form sửa đổi (hình 19)

- Để 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 (visibility) của các thuộc tính và phương thức của lớp, chúng tôi thống nhất như sau: private được thể hiện bằng dấu trừ (-), protected được thể hiện bằng dấu thắng (#) còn public được thể hiện bằng dấu cộng (+) ngay phía trước thuộc tính và 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

Một trường đại học tổ chức các seminar về các vấn đề chuyên môn cho sinh viên Có nhiều nhóm sinh viên tham gia seminar, mỗi nhóm có một chủ đề lớn (ví dụ công nghệ phần mềm, mạng máy tính…) và có một giảng viên phụ trách Các nhóm Seminar diễn ra trong một khoảng thời gian nhất định và có lịch cố định vào các tuần

Yêu cầu của nhà trường là có một ứng dụng để quản lý công tác thực hiện seminar này: tạo các nhóm seminar, chỉ định giáo viên phụ trách, công bố thông tin về seminar cho sinh viên và cho sinh viên đăng ký tham dự

Trong phần này, chúng tôi thực hiện quá trình xây dựng hệ thống trên theo quy trình đã trình bày ở phần II.2.1 bằng các luật và thuật toán làm mịn, các thao tác được thực hiện trên FM Tool Các thao tác nếu vi phạm các luật làm mịn sẽ bị công cụ đưa ra thông báo và không cho phép thực hiện Do mục đích của case study này là để thử nghiệm các lý thuyết và công cụ ở trên nên chúng tôi chỉ thực hiện công 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, khi thực hiện việc phân tích bài toán, từ mô hình nghiệp vụ, đặc biệt là mô hình khái niệm miền lĩnh vực của bài toán trên ta có hệ thống khởi tạo ban đầu APP 0 gồm các lớp Seminar, Student và Teacher (hình 20)

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:

- Lớp Seminar: o Private DateTime startTime //thời gian bắt thực hiện đầu nhóm seminar này o Private DateTime endTime //thời gian kết thúc nhóm seminar này o Private String timeInWeek //mô tả thời gian định kỳ hàng tuần o Private String topic //tên chủ đề của seminar

- 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

Qua nhận xét thấy hai lớp Teacher và Student có cùng thuộc tính name và phương thức PrinInfo(), hơn nữa trong thực tế vẫn có thể tổng quát hóa hai thực thể này tương ứng này bằng danh từ “Person” nên ta thêm lớp Person vào hệ thống và tạo các quan hệ tổng quát hóa từ lớp Teacher và Student đến lớp Person Thêm vào đó ta chuyển thuộc tính name của hai lớp này lên lớp cha Person

Làm mịn hệ thống theo định hướng mẫu thiết kế là một tư tưởng tốt và làm cho hệ thống được cấu trúc tốt hơn Áp dụng mẫu Stategy [20] vào đây, ta có thể thực hiện thao tác chuyển phương thức PrintInfo() của các lớp Teacher và Student lên lớp cha

Thực tế là trong mẫu Stategy, tính đa hình của hướng đối tượng được thể hiện rất rõ và các thuật toán MoveMethod, Polymorphism được áp dụng vào đây Sau bước này ta thu được đặc tả hệ thống APP 3 (hình 23) được làm mịn từ APP 2 : 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 công cụ này là một trong những nỗ lực nhằm hiện thực hóa việc phát triển phần mềm hướng đối tượng theo phương pháp hình thức Chúng tôi đã tiến hành xây dựng và cho ra đời FM Tool – một công cụ bước đầu có thể sử dụng được trong thực tế với một số chức năng khá cơ bản Sử dụng công cụ ta sẽ thu được một đặc tả thiết kế cuối cùng của hệ thống là một đặc tả lớp thiết kế trong XML Do cách đặc tả hệ thống rất gần gũi với mô hình lớp thiết kế của UML, nên có thể sử dụng các công cụ có sẵn như Rational Rose để chuyển thiết kế đó sang các ngôn ngữ lập trình hướng đối tượng một cách dễ dàng Việc chuyển đổi đặc tả sang công cụ khác cũng được thực hiện tự động qua hai bước: xuất đặc tả theo chuẩn XMI ra file XML và sau đó nhập đặc tả vào các công cụ khác từ file xuất ra của FM Tool

Tuy nhiên công cụ chúng tôi mới chỉ hỗ trợ các phép biến đổi cơ bản, còn nhiều phép biến đổi phức tạp và tinh tế khác chúng tôi chưa đề cập đến như: hiện thực hóa một giao diện, các phép biến đổi trên các phương thức,… Trong tương lai chúng tôi sẽ tiếp tục nghiên cứu xây dựng các thuật toán khác và xây dựng bổ sung chúng vào công cụ Chúng tôi cũng sẽ tích hợp chức năng sinh mã lập trình mô hình thiết kế cuối cùng để giúp người sử dụng tự động hóa việc sinh 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, C#