Tải bản đầy đủ (.pdf) (81 trang)

Phương pháp hình thức trong việc phát triển hệ thống hướng đối tượng

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (1.78 MB, 81 trang )


ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
#"

Nguyễn Hoàng Hà


PHƯƠNG PHÁP HÌNH THỨC TRONG VIỆC
PHÁT TRIỂN HỆ THỐNG HƯỚNG ĐỐI TƯỢNG

Ngành: Công Nghệ Thông Tin
Chuyên ngành: Công Nghệ Phần Mềm
Mã số: 68 40 10
LUẬN VĂN THẠC SĨ
NGƯỜI HƯỚNG DẪN KHOA HỌC:

PGS.TS Nguyễn Văn Vỵ



HÀ NỘI – 2007


Mục lục
DANH MỤC CÁC KÝ HIỆU, CÁC CHỮ VIẾT TẮT 1
DANH MỤC CÁC HÌNH VẼ 2
DANH MỤC CÁC BẢNG 4
MỞ ĐẦU 5 U
Chương I: GIỚI THIỆU CHUNG 7
I.1. Phương pháp phát triển phần mềm hướng đối tượng 7


I.1.1. Khái niệm 8
I.1.2. Các ưu điểm của phương pháp hướng đối tượng 8
I.2. Tiến trình thống nhất 9
I.2.1. Khái niệm về tiến trình thống nhất 9
I.2.2. Các đặc trưng của tiến trình thống nhất 10
I.2.3. Vòng đời của một tiến trình thống nhất 14
I.2.4. Một tiến trình tích hợp 16
I.3. Ngôn ngữ hình thức trong phát triển phần mềm 16
I.3.1. Mục tiêu của việc áp dụng phương pháp hình thức 16
I.3.2. Ưu điểm của phương pháp hình thức 17
I.3.3. Ngôn ngữ đặc tả hình thức 17
I.4. Mục tiêu và nội dung của đề tài 18
Chương II: ĐẶC TẢ VÀ LÀM MỊN HỆ THỐNG ĐỐI TƯỢNG VỚI rCOS 19
II.1. rCOS – Một phép làm mịn hệ thống đối tượng 19


II.1.1. UTP – cơ sở của rCOS 19
II.1.2. Đặc tả hệ thống đối tượng bằng rCOS 20
II.1.3. Lý thuyết làm mịn hệ thống đối tượng 24
II.2. Một tiến trình phát triển đặc tả hệ thống hướng đối tượng 29
II.2.1. Tổng quát 29
II.2.2. Các bước của tiến trình 31
II.3. Kết chương 40
Chương III: XÂY DỰNG CÔNG CỤ 41
III.1. Đặt vấn đề 41
III.2. Phân tích hệ thống 42
III.2.1. Xác định yêu cầu 42
III.2.2. Phát triển biểu đồ miền lĩnh vực 43
III.2.3. Xây dựng các mô hình ca sử dụng 45
III.2.4. Phát triển các biểu đồ lớp khái niệm 47

III.3. Thiết kế hệ thống 48
III.3.1. Biểu đồ lớp thiết kế 48
III.3.2. Biểu diễn thông tin đặc tả hệ thống 50
III.4. Cài đặt thử nghiệm 52
III.4.1. Môi trường và công cụ 52
III.4.2. Công cụ FM Tool 53
III.5. Tiến hành một case study với FM Tool 56
III.5.1. Khởi tạo hệ thống 56
III.5.2. Bổ sung các thuộc tính 57


III.5.3. Bổ sung các phương thức 58
III.5.4. Tổng quát hóa 59
III.5.5. Chuyển đặc tả sang công cụ CASE khác 60
III.6. Hai hướng sử dụng FM Tool 61
III.7. Kết luận chương 63
KẾT LUẬN 64
DANH MỤC CÁC CÔNG TRÌNH CỦA TÁC GIẢ 66
TÀI LIỆU THAM KHẢO 67
PHỤ LỤC 71

-1-
DANH MỤC CÁC KÝ HIỆU, CÁC CHỮ VIẾT TẮT
Ký hiệu Tiếng Anh Ý nghĩa
CASE Computer Aided Software
Engineering
Kỹ nghệ phần mềm được trợ
giúp bởi máy tính.
DTD Document type definition Định nghĩa dạng tài liệu: đặc tả
về thông tin định dạng tài liệu

viết bằng XML
MDA Model driven architecture Kiến trúc định huớng mô hình
MOF Meta object facility Cách đặc tả siêu đối tượng
OMG Object Management Group Một tổ chức của các hãng phần
mềm phát triển hướng đối tượng.
OOA Object – Oriented Analysis Phân tích hướng đối tượng
OOD Object – Oriented Design Thiết kế hướng đối tượng
OOP Object – Oriented Programming Lập trình hướng đối tượng
rCOS Relation Calculus of Object
System
Phép làm mịn quan hệ của hệ
thống đối tượng.
RUP Rational Unified Process Tiến trình thống nhất
UTP Unified Theory Programming Lý thuyết lập trình thống nhất
XMI XML Metadata Interchange Trao đổi siêu dữ liệu bằng XML
XML Extensible Markup Language Ngôn ngữ XML, một ngôn ngữ
đánh dấu có thể được người
dùng tự định nghĩa, mở rộng

-2-
DANH MỤC CÁC HÌNH VẼ
Hình 1. Tiến trình phát triển phần mềm 9
Hình 2. Ca sử dụng điều khiển các hoạt động phát triển 11
Hình 3. Mô hình hoá kiến trúc hệ thống 13
Hình 4. Một vòng đời hệ thống với các pha và bước lặp 14
Hình 5. Luồng công việc trong các pha và các bước lặp khác nhau 15
Hình 6. Biểu đồ lớp của hai khai báo lớp cdelcs
1
và cdecls
2

28
Hình 7. Ý tưởng cho phương pháp giải quyết vấn đề 30
Hình 8. Quan hệ phụ thuộc A phụ thuộc B qua một phương thức 38
Hình 9. Gói mô tả các khái niệm thuộc biểu đồ lớp UML theo OMG 44
Hình 10. Biểu đồ khái niệm miền lĩnh vực 45
Hình 11. Biểu đồ ca sử dụng mức gộp 45
Hình 12. Biểu đồ ca sử dụng quản lý các đặc tả hệ thống 46
Hình 13. Biểu đồ ca sử dụng phát triển và làm mịn đặc tả hệ thống 47
Hình 14. Biểu đồ lớp khái niệm tổng quát 48
Hình 15. Biểu đồ lớp thiết kế của hệ thống 49
Hình 16. So sách cách định nghĩa XML và UML của OMG 50
Hình 17. Giao diện công cụ FM Tool 53

-3-
Hình 18. Sửa đồi đối tượng bằng cách nhấn phải chuột và chọn Properties 55
Hình 19. Form sửa đổi các thuộc tính của một lớp 55
Hình 20. Khởi tạo hệ thống cho đặc tả APP
0
57
Hình 21. Mô hình UML tương ứng với APP
1
58
Hình 22. Mô hình UML tương ứng với APP
2
59
Hình 23. Mô hình UML tương ứng với APP3 60
Hình 24. Đặc tả được chuyển sang công cụ Power Designer 61
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 62



-4-
DANH MỤC CÁC BẢNG
Bảng 1. Ví dụ làm về làm mịn khai báo lớp 25
Bảng 2. Ví dụ về biến đổi cấu trúc khai báo lớp 27
Bảng 3. Bảng tổng hợp chức năng của công cụ 43

-5-
MỞ ĐẦU
Ngày nay thật hiếm có lĩnh vực nào lại không có sự tham gia của phần mềm. Sự
phát triển nhanh chóng của phần cứng và sự gia tăng rất nhanh của nhu cầu sử dụng
phần mềm đã làm cho việc phát triển phần mềm ngày càng phức tạp. Ngoài nhu cầu
phát triển những hệ thống phần mềm có quy mô lớn và phức tạp thì yêu cầu bảo trì các
hệ thống đó cũng ngày càng trở nên khó khăn. Thách thức của ngành công nghiệp
phần mềm hiện nay là làm thế nào phát triển phần mềm thương mại với chất lượng
cao: tin cậy, dễ mở rộng và bảo trì, phù hợp với yêu cầu người dùng đồng thời giá
thành và thời gian phát triển phần mềm phải không được vượt quá mong đợi. Trong
những năm gần đây, công nghệ phần mềm hướng đối tượng và các công cụ tự động trợ
giúp cho nó đã trờ thành một giải pháp công nghệ hữu hiệu cho nghành công nghiệp
phần mềm. Tiếp cận hướng đối tượng đã tỏ rõ nhiều ưu điểm so với các cách tiếp cận
khác và trở thành một phương pháp phổ biến trong công nghệ phần mềm.
Bên cạnh đó, việc áp dụng phương pháp hình thức vào quá trình phát triển phần
mềm từ lâu đã là một phương án tốt cho việc phát triển phần mềm, đặc biệt đối với các
hệ thống đòi hỏi sự chính xác cao. Phương pháp hình thức với việc sử dụng các công
cụ toán học đã làm cơ sở cho việc đặc tả, chứng minh tính chính xác và kiểm chứng
các hệ thống phần mềm.
Việc kết hợp hai phương pháp trên trong phát triển phần mềm là một ý tưởng
tốt, giúp cho chúng có thể bổ sung cho nhau. Đã có nhiều công trình nghiên cứu về
vấn đề này và các tác giả đã giải quyết được một số khía cạnh vấn đề trong những mặt
khác nhau. Trong khuôn khổ luận văn thạc sỹ “Phương pháp hình thức trong việc phát

triển hệ thống hướng đối tượng” này, tôi hy vọng sẽ đóng những nghiên cứu của mình
vào xu hướng trên. Bố cục của luận văn gồm phần mở đầu, phần kết luận và ba
chương.

-6-
Chương I trình bày những khái niệm cơ bản, những vấn đề liên quan đến phát
triển phân mềm hướng đối tượng và phương pháp hình thức. Chương này cũng đề ra
các vấn đề và nội dung nghiên cứu của luận văn này.
Trong chương II, một tiến trình phát triển phần mềm tập trung vào khung nhìn
biểu đồ lớp được đề xuất trong đó đặc tả hệ thống, các phép biến đổi, luật làm mịn
được thể hiện và chứng minh bằng rCOS.
Cuối cùng, chương III trình bày những nghiên cứu của tôi trong việc xây dựng
một phần mềm công cụ trợ giúp cho quá trình phát triển phần mềm hướng đối tượng,
cơ sở lý thuyết của chương này được vận dụng từ các nghiên cứu trong chương II.
Phần kết luận nêu tóm tắt các vấn đề đã được trình bày trong luận văn và những
vấn đề tồn tại cần tiếp tục nghiên cứu.
Ngoài ra trong phần phụ lục có trình bày nội dung một file XML theo chuẩn
XMI được xuất ra bởi công cụ xây dựng trong chương III. Bên cạnh đó, luận văn có
các phần như: danh mục các từ viết tắt, danh sách các hình vẽ, các bảng và tài liệu
tham khảo để giúp cho người đọc thuận tiện trong việc tìm hiều nội dung luận văn.

-7-
Chương I: GIỚI THIỆU CHUNG
I.1. Phương pháp phát triển phần mềm hướng đối tượng
Một trong những thách thức đối với ngành công nghiệp phần mềm là làm thế
nào phát triển các phần mềm với chất lượng cao, nhanh chóng và dễ bảo trì trong khi
các hệ thống ngày càng lớn và phức tạp
[30]. Điều đó xuất phát từ những nguyên nhân
sau:
- Nhu cầu của người dùng đối với phần mềm ngày một cao do sự phát triển như

vũ bão của internet và do yêu cầu tin học hóa các lĩnh vực của cuộc sống.
- Năng lực xử lý của phần cứng tăng nhanh (theo định luật Moore: Năng lực của
máy tính tăng gấp đôi sau 18 tháng) đặt ra yêu cầu làm thế nào để các hệ thống
phần mềm có thể tận dụng tiềm năng đó.
Vào những năm 70 của thế kỷ trước cuộc “khủng hoảng phần mềm” đã diễn ra
và đã đặt ra cho việc phát triển phần mềm nhiều yêu cầu và thách thức
[28]. Từ đó đã
có nhiều nhiều lý thuyết, phương pháp luận và kỹ thuật được nghiên cứu, đề xuất và
việc phát triển phần mềm dần trở thành một ngành công nghiệp. Từ sau năm 1990
phương pháp phát triển phần mềm hướng đối tượng ra đời và nhanh chóng đóng một
vai trò quan trọng. Phương pháp hướng đối tượng ngày càng mạnh mẽ và trở nên phổ
biến cho việc xây dựng các hệ thống phần mềm lớn và phức tạp. Cùng với sự ra đời và
phát triển của các ngôn ngữ lập trình hướng đối tượng phương pháp mới này đã dần
trở thành xu thế trong công nghệ phần mềm. Đặc biệt khi ngôn ngữ mô hình hóa thống
nhất UML được tổ chức OMG công nhận là chuẩn công nghiệp, lúc này các công cụ
CASE đã hỗ trợ hầu hết các giai đoạn phát triển phần mềm hướng đối tượng thì
phương pháp hướng đối tượng đã gần như hoàn thiện và tỏ rõ ưu thế so với các
phương pháp khác.

-8-
I.1.1. 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.
I.1.2. 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ệ
thống chất lượng ở mức cao hơn.

-
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.
I.2. Tiến trình thống nhất
I.2.1. 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.
-9-

-10-
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.
I.2.2. 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.
-11-


-12-
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.
-13-

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.
I.2.3. 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.
-14-

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

-16-
I.2.4. 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].
I.3. Ngôn ngữ hình thức trong phát triển phần mềm
Trong kỹ nghệ phần mềm phương pháp hình thức là một kỹ thuật dựa trên toán
học để đặc tả, phát triển và kiểm chứng hệ thống. Phương pháp hình thức bao gồm
ngôn ngữ đặc tả hình thức và lập luận hình thức
[31].
I.3.1. 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.

-17-
-
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.
I.3.2. Ư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.
I.3.3. 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.

-18-
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.
I.4. 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…


-19-
Chương II: ĐẶC TẢ VÀ LÀM MỊN HỆ THỐNG ĐỐI TƯỢNG
VỚI rCOS
II.1. 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.

-20-
 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
Æ
(<x11:T11, x12:T12, … x1i:T1i>),…mk
Æ
(<xk1:Tk1,
xk2:Tk2, … xki:Tki>)}.
 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.

-21-
- 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…)
II.1.2.1. Khai báo lớp
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 ℓ
}

×