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

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

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 5U 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

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

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

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 cdelcs1 và cdecls2 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 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ả APP0 57

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

Hình 22 Mô hình UML tương ứng với APP2 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

DANH MỤC CÁC BẢNG

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

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

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

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

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ệ

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

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

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

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

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

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

- 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

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…

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

ƒ 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

- 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] {

Trong đó:

- 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

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

Phương thức gọi le.m(e, v, vr) xác định đúng nếu le là đối tượng không rỗng và

m(x, y, z) là phương thức đã được khai báo trong kiểu le Khi nó đã được xác định

đúng, việc thực hiện các lệnh gán các giá trị của các tham số thực v và vr cho các tham

số hình thức x và z của m của các đối tượng hoạt động le tham chiếu tới, rồi thực hiện

thân của phương thức trong môi trường của lớp đối tượng hoạt động Sau khi thực hiện

các thân cuối cùng, giá trị của tham biến kết quả và tham biến giá trị kết quả y và z được trả lại hợp qui cách với các tham số thực r và vr

Lệnh tạo đối tượng mới C.new(x) được xác định đúng nếu C là lớp đã được khai báo Sự thực hiện lệnh này sẽ tạo ra một đối tượng mới của lớp C với biến tham chiếu

là x và gắn giá trị khởi đầu của các thuộc tính trong lớp C với giá trị các thuộc tính của

x

II.1.3 Lý thuyết làm mịn hệ thống đối tượng

Chúng ta sẽ xem xét một số khái niệm liên quan tới quá trình làm mịn mô hình

hệ thống [15]:

Định nghĩa 1 (làm mịn thiết kế): Thiết kế D 2 = (α, P 2 ) là thiết kế làm mịn của thiết kế D 1 =(α, P 1 ) được ký hiệu bởi D 1⊑ D 2 , nếu P 2 kế thừa P 1 , nghĩa là:

∀ x, x’, ok, ok’ • (P 2⇒ P ) 1

Ở đây x, x’ là các biến chứa trong α, ok và ok thể hiện tính hợp lệ của trạng thái

khởi đầu và cuối cùng của chương trình Nếu hai thiết kế không có cùng bảng chữ cái, chúng ta có thể dùng một ánh xạ làm mịn giữa hai không gian trạng thái (xem định nghĩa 2)

D 1 =D 2 nếu và chỉ nếu D 1⊑ D 2 và D 2⊑ D 1

Ví dụ: Giả sử lớp C ∈ CNAME, <a, int, d> ∈ attr(C), get(∅, int z, ∅){z:=a} và update(){a := a+z} ∈ op(C), ta có:

D = cdecls ● ({x: C, y: int}, C.new(x); x.update(); x.get(y)) 1

D = cdecls ● ({x: C, y: int}, C.new(x); x.update(); x.get(y); C.new(x)) 2

Theo mô hình tính toán rCOS và định nghĩa trên ta có:

∀ x, x’, y, y’, ok, ok’ • (P 2⇒ P ) nên 1 D 1⊑ D 2

Định nghĩa 2 (làm mịn thiết kế qua một ánh xạ): ρ(α 2 , α 1 ) là ánh xạ nhiều-một

từ không gian trạng thái α 2 tới không gian trạng thái α 1 Thiết kế D 2 =(α 2 , P 2 ) là làm mịn của thiết kế D 1 =(α 1 ,P 1 ) qua ánh xạ ρ, ký hiệu D1 ⊑ρ D 2, nếu:

(true ⊢ ρ(α 2 ,α’ 1 ); P 1 )⊑ (P 2 ; true ⊢ ρ(α 2 , α’ 1 ))

Định nghĩa 3 (làm mịn hệ thống): Cho S 1 = cdecls 1 ●P 1 và S 2 =cdecls 2 ●P 2 là các

hệ thống đối tượng có cùng một tập các biến chung externalvar S 2 là làm mịn của S 1 ,

được ký hiệu S1 ⊑sys S 2, nếu ∀ x, x’, ok, ok’ • (S 2⇒ S 1 )

Ví dụ: Xét hai khai báo cdecls1 và cdecls2 trong bảng sau:

Bảng 1 Ví dụ làm về làm mịn khai báo lớp

Trong khai báo lớp cdecls 2 cung chỉ cấp thêm một phương thức get() nên với mọi

dịch vụ của cdecls 1 cũng đều có thể cung cấp cdecls 2 bởi do đó với mọi Main ta có:

cdecls 1 • Main ⊑sys cdecls 2• Main

Định nghĩa 4 (làm mịn khai báo lớp): Cho cdecls 1 và cdecls 2 là hai phần khai báo lớp cdecls 1 là làm mịn của cdecls 2 , được ký hiệu cdecls1 ⊑class cdecls 2 nếu như

cdecls 2 có thể thay thế cdecls 1 trong bất kỳ hệ thống đối tượng:

cdecls 1⊑class cdecls 2 =def∀Main • ( cdecls 1• Main ⊑sys cdecls 2• Main)

Định nghĩa 4 (phép biến đổi cấu trúc khai báo lớp): Cho cdecls 1 và cdecls 2 là

hai phần khai báo lớp Một phép biến đổi từ cdecls 2 thành cdecls 1 là một quan hệ giữa

không gian đối tượng ∑ 2 của cdecls 2 và không gian đối tượng ∑ 1 của cdecls 1 được biểu

diễn true ⊢ ρ (Ω 2 , Ω’ 1) (với Ω là cấu trúc khai báo lớp) nếu thỏa các điều kiện sau:

- cdecls 2 có tất cả các lớp public như trong cdecls 1 nghĩa là

true ⊢ pubcname 1⊆ pubcname 2

- Với mỗi lớp public C có mặt trong cả cdecls 1 và cdecls 2 : cdecls 2 cung cấp

ít nhất các phương thức mà cdecls 1 cung cấp tức là với mọi C ∈ pubname

ta có Sig(op1 (C)) ⊆ Sig(op 2 (C))

Ví dụ: xét hai khai báo cdecls 1 và cdecls 2 trong bảng 2 Hình 6 biểu diễn các biểu

đồ lớp của hai khai báo đó

Phiên bản trừu tượng cdecls 1 chứa hai lớp C và C1, C1 có hai thuộc tính integer

a và b, và hai phương thức geta() trả về giá trị của thuộc tính a, updatea() tăng giá trị

của a lên một lượng bằng đối số truyền vào Lớp C chứa một thuộc tính o có kiểu C1

và phương thức geta() (gọi phương thức geta() của o) và updatea() (cũng đơn giản chỉ

là gọi phương thức tương ứng của o)

Phần khai báo cdecls 2 triển khai làm mịn cdecls 1 bằng 4 lớp khác biệt và đều là

lớp private C 2 , C 3 , C 4 , C5 trong đó:

- C 2 đóng vai trò một giao diện qua C như là C 1 mà không có thuộc tính

integer nào cả, chỉ có các đối tượng o 3 , o 4 , o 5 tham chiếu đến các đối

tượng thuộc lớp C 3 , C 4 , C5

- C 1 a được cài đặt bằng tổng C 3 a 3 và C 4 a 4

- C 1 b được cài đặt bằng C 5 a 5

- Phương thức geta() của C 2 được cài đặt bằng cách lấy giá trị của các

thuộc tính trong C 3 và C 4 và sao đó cộng chúng với nhau

- Phương thức updatea() trong C 2 thực hiện một biểu thức cập nhật không

tiền định (cập nhật thuộc tính o 3 hoặc o 4)

op:

geta( ∅, x: int, ∅){

o.geta( ∅, x, ∅) };

updatea(x: int, ∅, ∅) { o.updatea(x, ∅, ∅) }

};

private class C1 { pri: <a: int, 0>, <b: int, 0>;

op:

geta( ∅, x: int, ∅) {

x := a };

updatea(x: int, ∅, ∅) {

a := a + x }

};

Bảng 2 Ví dụ về biến đổi cấu trúc khai báo lớp

Hình 6 Biểu đồ lớp của hai khai báo lớp cdelcs 1 và cdecls 2

Chúng ta định nghĩa một phép biến đổi cấu trúc khai báo lớp ρ từ cdecls 2 đến

cdecls 1 như sau:

C.o’ = C.o∧

true ⊢ C 1 a’ = C 2 o 3 a 3 + C 2 o 4 a 4 ∧

C.b’ = C 2 o 5 a 5

Chúng ta nói rằng ρ là phép biến đổi nhiều một nếu với mỗi đối tượng o 1: dưới

cdecls 1 chỉ có một o 2 : C dưới cdecls 2 với ρ(α 2 , α 1 )

Định lý 3 trong [15] chứng tỏ rằng nếu có phép biến đổi cấu trúc lớp

(nhiều-một) true ⊢ ρ (Ω 2 , Ω’ 1) từ cdecls 2 thành cdecls 1 thì cdecls 2 là khai báo lớp làm mịn

của cdecls 1

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

II.2.1 Tổng quát

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

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

Quasơ đồ 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) Format: addClassName ()

Begin

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

2 CNAME := CNAME ∪ N

3 Kết thúc End

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

APP 0 ⊑ APP 1 ⊑… ⊑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:

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

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) AddAtribute (S, C, newAatt {T x = d})

Begin

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

3 att(C) := att(C) ∪ newAatt

4 Dừng End

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

Tiếp theo là chuyển các thuộc tính kiểu private cần thiết sang kiểu protected để

được hỗ trợ các dịch vụ nhiều hơn Muốn vậy, ta sẽ áp dụng luật chuyển đổi kiểu thuộc tính sau:

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)

//Output: S’ = (α’, P) và attr ∈ prot(C)

ChangeAttPriToPro (S, C, attr) Begin

1.pri(C) := pri(C)\ attr

2 prot(C) := prot(C) ∪ attr End

Bằng cách tương tự, ta cũng có thể xây dựng các thuật toán chuyển kiểu thuộc

tính protected sang kiểu public Sau mỗi bước thực hiện các công việc làm mịn trên sẽ

thu được một mô hình thống mới và ta có: Mô hình khái niệm thô ⊑ Mô hình khái niệm được làm mịn

c) Bổ sung các phương thức cho lớp

Mô hình thiết kế là mô hình gồm các lớp có chứa đầy đủ thuộc tính và phương thức Bằng cách bổ sung các phương thức cho các lớp của mô hình khái niệm ta được

mô hình thiết kế Có thể áp dụng các luật bổ sung phương thức như sau:

N[op]; cdecls ⊑ N[op ∪ m(paras) {c}]; cdecls

Thuật toán bổ sung các phương thức vào một lớp có thể viết như sau:

d) Thêm các quan hệ giữa các lớp

Trong UML, một mối quan hệ giữa các lớp thể hiện rằng các lớp có mối liên quan tác động đến nhau, thể hiện bằng ký pháp có đường liên kết giữa các lớp tham gia mối quan hệ Có 5 loại mối quan hệ: thừa kế (còn gọi là tổng quát hóa), phụ thuộc (dependency), liên kết (association), kết tập (aggregation) và hợp thành (composition) [2], [8], [27] Trong khuôn khổ luận văn này, các nghiên cứu chỉ tập trung vào các quan hệ giữa hai lớp, các mối quan hệ có nhiều hơn hai lớp tham gia có thể được biến đổi về các mối quan hệ hai lớp

Một mối quan hệ 2 lớp trong được mô tả trong đại số quan hệ bằng tích đề các CNAME x CNAME x Không_gian_đặc_tính_của_quan_hệ Một đặc tính của quan hệ bao gồm các thông tin như loại quan hệ, tên quan hệ, vai trò của từng lớp, bản số của từng lớp

Định nghĩa: Gọi tập các quan hệ của đặc tả hệ thống là RELATIONSHIP, một khai

báo các lớp cdecls có tập các mối quan hệ RELATIONSHIP được ký hiệu

cdecls(RELATIONSHIP) Định nghĩa RELATIONSHIP như sau:

RELATIONSHIP = {relation (type, name, A, B, RoleA, RoleB, mulA, mulB) | type ∈ RELTYPE, name ∈ String, A ∈ CNAME, B ∈ CNAME, RoleA ∈ String, RoleB ∈ String, mulA ∈ MULTIPLICITY, mulB ∈ MULTIPLICITY}

Trong đó:

ƒ RELTYPE = {inheritance, dependency, association, aggregation, composition}.

o Inheritance: quan hệ thừa kế A thừa kế B

o Dependency: quan hệ phụ thuộc A phụ thuộc B

o Association: quan hệ liên liên kết giữa A và B Quan hệ này có thể một chiều (từ A đến B tức là A biết B chứ B không biết A) hoặc 2 chiều (cả A và B đều biết nhau)

o Aggregation: quan hệ kết hợp A chứa B