Giáo trình Phân tích thiết kế đối tượng bằng uml

182 trang huongle 5570

Download

Bạn đang xem 20 trang mẫu của tài liệu "Giáo trình Phân tích thiết kế đối tượng bằng uml", để tải tài liệu gốc về máy bạn click vào nút DOWNLOAD ở trên

Tài liệu đính kèm:

giao_trinh_phan_tich_thiet_ke_doi_tuong_bang_uml.pdf

Nội dung text: Giáo trình Phân tích thiết kế đối tượng bằng uml

GIÁO TRÌNH Phân tích thiết kế đối tượng bằng UML
Phân tích, thiết kế hướng đối tượng bằng UM L Đoàn Văn Ban MỤC LỤC MỤC LỤC 1 LỜI NÓI ĐẦU 5 CHƯƠNG I: PHƯƠNG PHÁP HƯỚNG ĐỐI TƯỢNG VÀ QUÁ TRÌNH PHÁT TRIỂN HỆ THỐNG PHẦN MỀM 7 1.1. Giới thiệu 7 1.2. Giới thiệu về hệ thống phần mềm 8 1.2.1 Các đặc trưng của hệ thống 9 1.2.2 Phân loại hệ thống phần mềm 11 1.3. Sự phát triển hệ thống 13 1.3.1 Chu trình phát triển hệ thống 13 1.3.2 Mô hình hoá hệ thống 18 1.4 Các cách tiếp cận trong phát triển phần mềm 21 1.4.1 Cách tiếp cận hướng chức năng 21 1.4.2 Cách tiếp cận hướng đối tượng 23 1.5. Quá trình phát triển phần mềm hợp nhất 25 1.6. Kết luận 33 Câu hỏi và bài tập 33 CHƯƠNG II: UML VÀ QUÁ TRÌNH PHÁT TRIỂN PHẦN MỀM 35 2.1 Tổng quát về UML 35 2.1.1 Mục đích của UML 35 2.1.2 Quá trình phát triển phần mềm thống nhất với UML 36 2.1.3 Giới thiệu tổng quát về UML 37 2.1.4 Các phần tử của UML 39 2.2 Các khái niệm cơ bản của phương pháp hướng đối tượng 43 2.2.1 Các đối tượng 43 2.2.2 Lớp đối tượng 44 2.2.3 Các giá trị và các thuộc tính của đối tượng 45 2.2.4 Các thao tác và phương thức 46 2.3 Các mối quan hệ giữa các lớp 46 2.3.1 Sự liên kết và kết hợp giữa các đối tượng 46 - 1 -
Phân tích, thiết kế hướng đối tượng bằng UM L Đoàn Văn Ban 2.3.2 Bội số 48 2.3.3 Các vai trò trong quan hệ 49 2.3.4 Quan hệ kết nhập 49 2.3.5 Quan hệ tổng quát hoá 51 2.3.6 Kế thừa bội 52 2.3.7 Quan hệ phụ thuộc 54 2.3.7 Quan hệ hiện thực hoá 54 2.4 Các gói 55 2.5 Các qui tắc ràng buộc và suy diễn 56 2.7 Rational Rose và quá trình phát triển phần mềm thống nhất 58 Bài tập và câu hỏi 59 CHƯƠNG III: BIỂU ĐỒ CA SỬ DỤNG PHÂN TÍCH CÁC NHU CẦU CỦA HỆ THỐNG 60 3.1 Định nghĩa bài toán 60 3.2 Phân tích và đặc tả các yêu cầu hệ thống 63 3.2.1 Ca sử dụng 63 3.2.2 Tác nhân 64 3.2.3 Xác định các ca sử dụng và các tác nhân 65 3.2.3 Đặc tả các ca sử dụng 67 3.3 Biểu đồ ca sử dụng 70 3.4 Tạo lập biểu đồ ca sử dụng trong Rational Rose 74 Bài tập và câu hỏi 74 CHƯƠNG IV: PHÂN TÍCH HỆ THỐNG – MÔ HÌNH KHÁI NIỆM VÀ BIỂU ĐỒ LỚP 76 4.1 Mô hình khái niệm – mô hình đối tượng 76 4.2 Xác định các lớp đối tượng 77 4.3 Mối quan hệ giữa các lớp đối tượng 85 4.3.1 Đặt tên cho các quan hệ kết hợp 86 4.3.2 Các phương pháp xác định các mối quan hệ kết hợp 86 4.4 Biểu đồ lớp 88 4.4.1 Các loại lớp trong biểu đồ 88 4.4.2 Mẫu rập khuôn (stereotype) của các lớp 90 4.4.3 Biểu đồ lớp trong Hệ HBH 90 - 2 -
Phân tích, thiết kế hướng đối tượng bằng UM L Đoàn Văn Ban 4.5 Thuộc tính của lớp 91 4.5.1 Tìm kiếm các thuộc tính 94 4.5.2 Các thuộc tính của các lớp trong HBH 97 4.6 Các phương thức của lớp 98 4.7 Ghi nhận trong từ điển thuật ngữ 99 4.8 Thực hành trong Rational Rose 100 Câu hỏi và bài tập 101 CHƯƠNG V: MÔ HÌNH ĐỘNG THÁI: CÁC BIỂU ĐỒ TƯƠNG TÁC VÀ HÀNH ĐỘNG TRONG HỆ THỐNG 103 5.1 Mô hình hoá hành vi hệ thống 103 5.1.1 Các sự kiện và hành động của hệ thống 104 5.1.2 Sự trao đổi thông điệp giữa các đối tượng 106 5.2 Biểu đồ trình tự 106 5.2.1 Các thành phần của biểu đồ trình tự 107 5.2.2 Xây dựng biểu đồ trình tự 108 5.2.3 Các biểu đồ trình tự mô hình hành động của hệ HBH 109 5.2.4 Ghi nhận các hoạt động của các lớp đối tượng 111 5.2.5 Các hợp đồng về hoạt động của hệ thống 112 5.3 Biểu đồ trạng thái 114 5.3.1 Trạng thái và sự biến đổi trạng thái 115 5.3.2 Xác định các trạng thái và các sự kiện 116 5.3.3 Xây dựng biểu đồ trạng thái 117 5.4 Biểu đồ hoạt động 119 5.5 Sử dụng Rational Rose để tạo lập biểu đồ trình tự 121 5.6 Sử dụng Rational Rose để tạo lập biểu đồ trạng thái 122 Bài tập và câu hỏi 123 CHƯƠNG VI: THIẾT KẾ CÁC BIỂU ĐỒ CỘNG TÁC VÀ BIỂU ĐỒ THÀNH PHẦN CỦA HỆ THỐNG 124 6.1 Các biểu đồ cộng tác 125 6.2 Thiết kế các biểu đồ cộng tác và các lớp đối tượng 129 6.2.1 Ca sử dụng thực tế 130 6.2.2 Mẫu gán trách nhiệm 131 6.2.3 Mẫu gán trách nhiệm 132 - 3 -
Phân tích, thiết kế hướng đối tượng bằng UM L Đoàn Văn Ban 6.3 Thiết kế hệ thống HBH 138 6.4 Thiết kế chi tiết các biểu đồ lớp 144 6.5 Thiết kế biểu đồ cộng tác và hoàn thiện thiết kế biểu đồ lớp 152 6.5.1 Xây dựng biểu đồ cộng tác 152 6.5.2 Hoàn thiện thiết kế biểu đồ lớp 152 Bài tập và câu hỏi 153 CHƯƠNG VIII: KIẾN TRÚC HỆ THỐNG VÀ PHÁT SINH MÃ TRÌNH 154 7.1 Kiến trúc của Hệ thống 154 7.2 Biểu đồ thành phần 157 7.3 Biểu đồ triển khai 160 7.4 Ánh xạ các thiết kế sang mã chương trình 161 7.4.1 Tạo lập các định nghĩa lớp từ những thiết kế biểu đồ lớp 161 7.4.2 Định nghĩa hàm từ biểu đồ cộng tác 163 7.5 Danh sách một số lớp được định nghĩa trong C++ 165 7.6 Thực hành trên Rose 168 7.6.1 Xây dựng biểu đồ thành phần 168 7.6.2 Xây dựng biểu đồ triển khai 168 7.6.3 Phát sinh mã trình bằng Rose 168 Bài tập và câu hỏi 174 TÀI LIỆU THAM KHẢO 176 Danh sách thuật ngữ và các từ viết tắt 179 - 4 -
Phân tích, thiết kế hướng đối tượng bằng UM L Đoàn Văn Ban LỜI NÓI ĐẦU Nhiệm vụ của công nghệ thông tin nói chung, công nghệ phần mềm nói riêng là nghiên cứu các mô hình, phương pháp và công cụ để tạo ra những hệ thống phần mềm chất lượng cao nhằm đáp ứng được những nhu cầu thường xuyên thay đổi, ngày một phức tạp của thực tế. Nhiều hệ thống phần mềm đã được xây dựng theo các cách tiếp cận truyền thống tỏ ra lạc hậu, không đáp ứng được các yêu cầu của người sử dụng. Cách tiếp cận hướng đối tượng giúp chúng ta có được những công cụ, phương pháp mới, phù hợp để giải quyết những vấn đề nêu trên. Cách tiếp cận này rất phù hợp với cách quan sát và quan niệm của chúng ta về thế giới xung quanh và tạo ra những công cụ mới, hữu hiệu để phát triển các hệ thống có tính mở, dễ thay đổi theo yêu cầu của người sử dụng, đáp ứng được các tiêu chuẩn phần mềm theo yêu cầu của nền công nghệ thông tin hiện đại, giải quyết được những vấn đề phức tạp của thực tế đặt ra trong thế kỷ 21. Giáo trình này trình bày cách sử dụng ngôn ngữ mô hình hoá thống nhất UML (Unified Modeling Language) để phân tích và thiết kế hệ thống theo cách tiếp cận hướng đối tượng. Cách tiếp cận hướng đối tượng đặt trọng tâm vào việc xây dựng lý thuyết cho các hệ thống tổng quát như là mô hình cơ bản. Hệ thống được xem như là tập các thực thể tác động qua lại và trao đổi với nhau bằng các thông điệp để thực hiện những nhiệm vụ đặt ra. Các khái niệm mới của mô hình hệ thống hướng đối tượng và các bước thực hiện phân tích, thiết kế hướng đối tượng được mô tả, hướng dẫn thực hiện thông qua ngôn ngữ chuẩn UML cùng phần mềm công cụ hỗ trợ mô hình hoá Rational Rose. Giáo trình được biên soạn theo nhu cầu giảng dạy, học tập và nghiên cứu môn học “Phân tích, thiết kế hệ thống” của ngành Công nghệ thông tin; nội dung được biên soạn theo yêu cầu của chương trình đào tạo CNTT và dựa vào kinh nghiệm giảng dạy môn học này qua nhiều năm của tác giả trong các khoá đào tạo cao học, đại học tại các Đại học Quốc gia Hà Nội, Đại học Khoa học Huế, Đại học Đà Nẵng, Đại học Thái Nguyên, v.v. Giáo trình được trình bày trong bảy chương. Chương mở đầu giới thiệu những khái niệm cơ sở trong mô hình hoá, qui trình phát triển hệ thống và hai cách tiếp cận chính để phát triển các hệ thống phần mềm hiện nay là hướng thủ tục (hướng chức năng) và hướng đối tượng. Chương II giới thiệu ngôn ngữ mô hình hoá thống nhất UML và vai trò của nó trong quá trình phát triển phần mềm thống nhất. Vấn đề phân tích các yêu cầu của hệ thống và cách xây dựng biểu đồ ca sử dụng được nêu ở chương III. Chương IV trình bày những khái niệm cơ bản về các lớp đối tượng và các mối quan hệ của chúng trong không gian bài toán. Biểu đồ lớp cho phép biểu diễn tất cả những khái niệm đó một cách trực quan và thông qua mô hình khái niệm là biểu đồ lớp, chúng ta hiểu rõ hơn về hệ thống cần phát triển. Những biểu đồ tương tác, mô hình động thái thể hiện các hành vi và ứng xử của hệ thống được giới thiệu ở chương V. Dựa vào những kết quả phân tích ở các chương trước, hai chương tiếp theo nêu cách thực hiện để thiết kế các biểu đồ cộng tác cho từng nhiệm vụ, từng ca sử dụng của hệ thống và từ đó có được những thiết kế lớp, biểu đồ lớp chi tiết mô tả chính xác - 5 -
Phân tích, thiết kế hướng đối tượng bằng UM L Đoàn Văn Ban các nhiệm vụ được giao. Vấn đề quan trọng là lựa chọn kiến trúc cho hệ thống và khả năng ánh xạ những kết quả thiết kế sang mã chương trình trong một ngôn ngữ lập trình hướng đối tượng như C++, Java, Visual Basic, Oracle, v.v. được đề cập ở chương VII. Bài toán xây dựng “Hệ thống quản lý bán hàng” được chọn làm ví dụ minh hoạ xuyên suốt cả giáo trình để phân tích, thiết kế hệ thống phần mềm theo cách tiếp cận hướng đối tượng. Ngoài ra, phần phụ lục giới thiệu một số tài liệu phân tích, thiết kế để các bạn tham khảo thêm. Tác giả xin chân thành cám ơn các bạn đồng nghiệp trong Viện CNTT, các bạn trong Khoa CNTT, Đại học Khoa học Huế, các bạn trong Khoa CNTT, Đại học Quốc gia Hà Nội, Đại học Thái Nguyên về những đóng góp quí báu, hỗ trợ thiết thực và động viên chân thành để hoàn thành cuốn giáo trình này. Mặc dù đã rất cố gắng, nhưng giáo trình này chắc không tránh khỏi những sai sót. Chúng tôi rất mong nhận được các ý kiến góp ý của các thầy cô, những nhận xét của bạn đọc để hiệu chỉnh thành cuốn sách hoàn thiện. Hà Nội 2004 Tác giả - 6 -
Phân tích, thiết kế hướng đối tượng bằng UM L Đoàn Văn Ban CHƯƠNG I PHƯƠNG PHÁP HƯỚNG ĐỐI TƯỢNG VÀ QUÁ TRÌNH PHÁT TRIỂN HỆ THỐNG PHẦN MỀM Chương I trình bày các vấn đề cơ sở về: 9 Các khái niệm và đặc trưng cơ bản của hệ thống phần mềm, 9 Quá trình phát triển phần mềm hệ thống, 9 Các phương pháp phân tích và thiết kế hệ thống. 1.1. Giới thiệu Thách thức lớn nhất của loài người trong thế kỷ 21 là sự hỗn độn và mức độ phức tạp trong hầu hết các lĩnh vực của cuộc sống. Khoa học tính toán, tin học sẽ đóng vai trò rất quan trọng trong việc tăng thêm trí tuệ, khoa học cho con người nhằm giải quyết những vấn đề rất phức tạp trong mọi hoạt động của mình. Nền kinh tế của chúng ta ở thế kỷ này cũng phải chuyển sang nền kinh tế tri thức, nghĩa là luôn đổi mới và thay đổi, khác hẳn với nền kinh tế dựa vào vật chất. Để hiểu, để khống chế được độ phức tạp của những vấn đề đặt ra trong nền kinh tế tri thức và từ đó đưa ra được những giải pháp để giải quyết chúng thì chúng ta phải có những phương pháp khoa học và đúng đắn, phù hợp với các qui luật xã hội và tự nhiên. Bên cạnh việc nghiên cứu các phương pháp thích hợp đối với từng loại hệ thống, chúng ta cũng cần tìm hiểu từng bộ phận của chúng để mô hình hoá và xác định được quá trình hình thành của mỗi hệ thống. Như Pascal đã khảng định “Không thể hiểu được bộ phận nếu không hiểu toàn thể và không thể hiểu toàn thể nếu không hiểu được từng bộ phận”. Do vậy, nhiệm vụ của các ngành khoa học là đi nghiên cứu các quá trình, các qui luật tự nhiên, các tính chất và hành vi của hệ thống để mô hình hoá chúng và đề xuất những phương pháp để giải quyết những vấn đề xảy ra trong các hoạt động của con người sao cho hiệu quả nhất. Nhiệm vụ của công nghệ thông tin nói chung, công nghệ phần mềm nói riêng là nghiên cứu các mô hình, phương pháp và công cụ để tạo ra những hệ thống phần mềm chất lượng cao trong phạm vi hạn chế về tài nguyên nhằm đáp ứng được những nhu cầu thường xuyên thay đổi của khách hàng, giải quyết được những vấn đề phức tạp đặt ra trong thực tế. Trước những năm 60, chưa định hình các phương pháp rõ rệt cho quá trình phát triển phần mềm [19, 35]. Người ta xây dựng hệ thống phần mềm tương đối tuỳ tiện, theo sở thích và những kinh nghiệm cá nhân. Từ những năm 70 tới nay, nhiều mô hình, phương pháp phát triển phần mềm lần lượt ra đời. Mỗi phương pháp đều có những ưu, nhược điểm riêng, có thể được ưa chuộng ở nơi này, ở một số lĩnh vực nào đó nhưng lại không được ưa chuộng ở những nơi khác. Sự đa dạng và phong phú trong các phương pháp cũng có nghĩa là có sự không thống nhất, không chuẩn hoá. Tuy nhiên, trải qua thời gian, một số phương pháp đã tỏ ra có sức sống dẻo dai, - 7 -
Phân tích, thiết kế hướng đối tượng bằng UM L Đoàn Văn Ban đang được áp dụng rộng rãi trong thực tế. Trong số này phải kể trước hết những phương pháp có tên chung là các phương pháp có cầu trúc [7, 9, 19]. Những phương pháp này thống nhất trong cùng một cách tiếp cận, đó là hướng thủ tục và cùng một hướng tư duy (có cấu trúc và trên xuống), nhưng mỗi phương pháp lại chỉ đề cập đến một phương diện của quá trình phát triển phần mềm. Do vậy, người ta thường sử dụng một số phương pháp liên hoàn, bổ sung cho nhau trong cùng một đề án phát triển phần mềm phức tạp. Ngày nay nó vẫn chưa lạc hậu, vẫn còn phát huy tác dụng tốt cho những hệ thống có cấu trúc với những dữ liệu tương đối thuần nhất. Nhưng do sự phong phú về phương pháp luận và sự đa dạng về sự biểu diễn các khái niệm (các ký hiệu rất khác nhau, không thống nhất) dẫn tới khó có thể đưa ra được một qui trình thống nhất cho quá trình phát triển phần mềm. Mặt khác, nhiều vấn đề phức tạp mới xuất hiện, không chỉ yêu cầu tính toán lớn, xử lý phân tán, thường xuyên thay đổi các yêu cầu mà còn đòi hỏi phải quản lý với nhiều loại dữ liệu khác nhau, dữ liệu đa phương tiện, dữ liệu âm thanh, hình ảnh, v.v. Từ những năm 90, xuất hiện một trào lưu mới, mãnh liệt: đó là sự ra đời của các phương pháp hướng đối tượng [4, 5, 18, 21, 24]. Thay vì cách tiếp cận dựa vào chức năng, nhiệm vụ của hệ thống như các phương pháp có cấu trúc nêu trên, phương pháp hướng đối tượng lại dựa chính vào các thực thể (các đối tượng). Cách tiếp cận hướng đối tượng đặt trọng tâm vào việc xây dựng lý thuyết cho các hệ thống tổng quát như là mô hình khái niệm cơ sở. Hệ thống được xem như là tập các đối tượng tác động với nhau trên cơ sở truyền thông điệp để thực thi các nhiệm vụ đặt ra trong hệ thống đó. Cách tiếp cận này rất phù hợp với cách quan sát và quan niệm của chúng ta về thế giới xung quanh và tạo ra những công cụ mới, hữu hiệu để phát triển các hệ thống có tính mở, dễ thay đổi theo yêu cầu của người sử dụng, đáp ứng được các tiêu chuẩn phần mềm theo yêu cầu của nền công nghệ thông tin hiện đại, giải quyết được những vấn đề phức tạp của thực tế đặt ra trong thế kỷ 21. Một điều rất quan trọng trong công nghệ phần mềm là các khái niệm mới của mô hình hệ thống hướng đối tượng, các bước phát triển có thể đặc tả và thực hiện theo một qui trình thống nhất [2, 21] với một hệ thống ký hiệu chuẩn, đó là ngôn ngữ mô hình hoá hợp nhất UML (Unified Modeling Language) [3, 10], được sự hỗ trợ của những phần mềm công cụ như Rational Rose [17, 22]. Những công cụ này hỗ trợ rất hiệu quả cho các giai đoạn phân tích, thiết kế và lập trình hướng đối tượng. 1.2. Giới thiệu về hệ thống phần mềm Theo từ điển Larousse, “Tin học là tập hợp các ngành khoa học, kỹ thuật, kinh tế - xã hội vận dụng vào việc xử lý thông tin và sự tự động hoá”. Nếu vậy, có thể định nghĩa hệ thống tin học là hệ thống có mục đích xử lý thông tin và có sự tham gia của máy tính. Sự tham gia của máy tính trong một hệ thống tin học có thể ở nhiều mức độ khác nhau: Mức thấp: máy tính chỉ được sử dụng để giải quyết một số công việc đơn lẻ, như soạn thảo các công văn, báo cáo, các bảng biểu thống kê, hoá đơn, chứng từ, bảng tính lương, v.v. - 8 -
Phân tích, thiết kế hướng đối tượng bằng UM L Đoàn Văn Ban Mức trung bình: máy tính cùng với con người cộng tác, phân công với nhau để thực hiện một qui trình quản lý phức tạp, ví dụ, các hệ thống thông tin quản lý hành chính nhà nước, các dịch vụ công, các hệ thống điều hành tác nghiệp đang được xây dựng trong Chương trình Cải cách hành chính, Đề án 112 của Chính phủ giai đoạn 2001 – 2005, v.v. Mức cao: máy tính đóng vai trò chủ chốt trong quá trình xử lý thông tin, con người không can thiệt trực tiếp vào quá trình này mà chỉ có nhiệm vụ cung cấp thông tin đầu vào cho hệ thống và nhận được kết quả ra từ máy tính như các chương trình điều khiển các chuyến bay của các con tàu vũ trụ, các chương trình điều khiển các quá trình sản xuất tự động, những vấn đề về trí tuệ nhân tạo, v.v. Hệ thống tin học (phần mềm) do vậy, có thể được xem là tổ hợp các phần cứng, phần mềm có quan hệ qua lại với nhau, cùng hoạt động hướng tới mục tiêu chung thông qua việc nhận các dữ liệu đầu vào (Input) và sản sinh ra những kết quả đầu ra (Output) thường là ở các dạng thông tin khác nhau nhờ một quá trình xử lý, biến đổi có tổ chức. Một cách hình thức hơn chúng ta có thể định nghĩa phần mềm [13, 19] bao gồm các thành phần cơ bản như sau: Hệ thống các câu lệnh (chương trình) khi thực hiện thì tạo ra được các hoạt động và cho các kết quả theo yêu cầu, Các cấu trúc dữ liệu làm cho chương trình thực hiện được các thao tác, xử lý và cho ra các thông tin cần thiết, Các tài liệu mô tả thao tác và cách sử dụng hệ thống. 1.2.1 Các đặc trưng của hệ thống Hệ thống thông tin cũng giống như các hệ thống khác đều có những đặc trưng cơ bản như sau: 1. Mọi hệ thống đều có tính nhất thể hoá và đặc tính này được thể hiện thông qua: Phạm vi và qui mô của hệ thống được xác định như một thể thống nhất và hệ thống không thay đổi trong những điều kiện nhất định. Khi những điều kiện này không còn được đảm bảo thì hệ thống sẽ phải biến đổi theo. Tạo ra những đặc tính chung để thực hiện được các nhiệm vụ hay nhằm đạt được các mục tiêu chung mà từng bộ phận riêng lẻ không thể thực hiện được. 2. Trong sự hỗn độn, phức tạp của thế giới xung quanh, một hệ thống được tạo ra và phát triển thì phải có tính tổ chức, có thứ bậc. Nghĩa là: Mọi hệ thống luôn là hệ thống con của một hệ thống lớn hơn trong môi trường nào đó và chính nó lại bao gồm các hệ thống (các thành phần) nhỏ hơn. - 9 -
Phân tích, thiết kế hướng đối tượng bằng UM L Đoàn Văn Ban Giữa các thành phần của một hệ thống có sự sắp xếp theo quan hệ thứ bậc hay một trình tự nhất định. 3. Mọi hệ thống đều có cấu trúc: Chính cấu trúc của hệ thống quyết định cơ chế vận hành của hệ thống và mục tiêu mà nó cần đạt được. Cấu trúc của hệ thống được thể hiện bởi: Các phần tử được sắp xếp theo trật tự để cấu thành một hệ thống. Mối quan hệ giữa các thành phần liên quan chủ yếu đến loại hình, số lượng, chiều, cường độ, v.v. Những hệ thống có cấu trúc chặt thường được gọi là hệ thống có cấu trúc. Cấu trúc của hệ thống là quan trọng, nó có thể quyết định tính chất cơ bản của hệ thống. Ví dụ: kim cương và than đá đều được cấu tạo từ các phân tử các-bon, nhưng khác nhau về cấu trúc nên: kim cương vô cùng rắn chắc, còn tham đá thì không có tính chất đó. Sự thay đổi cấu trúc có thể tạo ra những đặc tính mới (sức trồi mới, hay còn gọi là những đột biến) của hệ thống và khi vượt quá một ngưỡng nào đó thì có thể dẫn tới việc phá vỡ hệ thống cũ. Ví dụ: công nghệ biến đổi gen: chính là làm thay đổi cấu trúc của các tế bào sinh học. Những nguyên lý di truyền và biến đổi gen của công nghệ sinh học cũng đang được nghiên cứu và ứng dụng trong công nghệ thông tin. 4. Mọi hệ thống đều biến đổi theo thời gian và không gian: Hệ thống nào cũng có một đời sống, từ lúc khai sinh đến lúc bị phế bỏ. Các hệ thống phải luôn thay đổi cho phù hợp với điều kiện thực tế theo thời gian và không gian, nghĩa là muốn tồn tại và phát triển thì phải biến đổi cho phù hợp với môi trường xung quanh theo qui luật tiến hoá của tự nhiên (Darwin). Sự khác nhau chủ yếu là tốc độ và khả năng nhận biết được về sự thay đổi đó. Mọi sự thay đổi luôn có mối liên hệ ngược (feedback) trong hệ thống và chịu sự tác động của qui luật “nhân - quả”. Hệ thống được đánh giá theo nhiều tiêu chí khác nhau [7, 13, 19, 24] và chưa có một hệ thống tiêu chí chuẩn để đánh giá cho các sản phẩm phần mềm. Ở đây chúng ta chỉ quan tâm đến một số tính chất quan trọng nhất hiện nay của các sản phẩm phần mềm. Một sản phẩm của công nghệ phần mềm hiện nay, ngoài những tính chất chung của các hệ thống nêu trên thì phải có các tính chất sau: Tính tiện dụng (usability): sản phẩm phải dễ sử dụng và tiện lợi cho người dùng, hỗ trợ để thực hiện các công việc tốt hơn. Muốn đạt được mục đích này thì phần mềm phải có giao diện thân thiện, phù hợp, có đầy đủ các tài liệu mô tả và có sự hỗ trợ kịp thời cho người sử dụng. - 10 -
Phân tích, thiết kế hướng đối tượng bằng UM L Đoàn Văn Ban Khả năng bảo hành và duy trì hoạt động (Maintainability): Hệ thống phải có khả năng cập nhật, đễ thay đổi, có khả năng mở rộng để thực hiện được những yêu cầu thay đổi của khách hàng. Tính tin cậy (Dependability): Tính tin cậy của phần mềm không chỉ thể hiện ở khả năng thực hiện đúng nhiệm đã được thiết kế và cả các khả năng đảm bảo an toàn, an ninh dữ liệu. Hệ thống phải thực hiện bình thường ngay cả khi có sự kiện bất thường xảy ra. Tính hiệu quả (Efficiency): Phần mềm không gây ra sự lãng phí các tài nguyên như bộ nhớ, bộ xử lý,các thiết bị ngoại vi, thời gian sử dụng, v.v. 1.2.2 Phân loại hệ thống phần mềm Nếu xét tới nội dung của thông tin được xử lý và tính chất của môi trường của hệ thống, người ta có thể phân hệ thống phần mềm theo các loại khác nhau [24, 35] như sau: 1. Hệ thống thông tin quản lý (Management Information System - MIS): hệ thống cung cấp các thông tin cần thiết cho công tác quản lý và điều hành của một doanh nghiệp, cơ quan, hay nói rộng ra là cho một tổ chức. Hạt nhân của hệ thống thông tin quản lý là một cơ sở dữ liệu (CSDL) chứa các thông tin phản ánh tình trạng hiện thời và các kết quả hoạt động sản xuất, kinh doanh của tổ chức đó. Hệ thống thu thập các thông tin từ môi trường hoạt động của doanh nghiệp, kết hợp với các thông tin có trong CSDL để kết xuất các thông tin mà các nhà quản lý cần, đồng thời thường xuyên cập nhật dữ liệu để giữ cho các thông tin ở trong CSDL luôn phản ánh đúng thực trạng hiện thời của tổ chức đó. Hệ thống thông tin quản lý thường được phân loại theo hai mức: Mức thấp, hay còn gọi mức tác nghiệp, hệ thống chỉ có nhiệm vụ in ra các bảng biểu, chứng từ giao dịch theo những biểu mẫu của cách xử lý thủ công (bằng tay) vẫn làm. Đó thường là các hệ thống xử lý dữ liệu như các hệ thống đơn hàng, quản lý nhân sự, quản lý thiết bị, vật tư, kế toán tài vụ, v.v. Mức cao, hay còn gọi mức điều hành, hệ thống phải đưa ra được các thông tin có tính chất chiến lược và kế hoạch giúp cho người lãnh đạo đưa ra được các quyết định đúng đắn trong công tác điều hành sự hoạt động của đơn vị, ví dụ, các hệ thống dịch vụ công, các hệ thống thông tin tổng hợp, các trang thông tin điều hành tác nghiệp của Tỉnh / Thành đang được xây dựng trong Đề án 112 của Chính phủ [36, 37, 38]. Những hệ thống như thế có thể phát triển được thành hệ hỗ trợ quyết định (Decision Support System – DSS). Đặc điểm của hệ hỗ trợ quyết định là bên cạnh CSDL còn có cơ sở các mô hình, các phương pháp mà khi lựa chọn để vận dụng lên các dữ liệu sẽ cho các lời giải, cho các kết quả theo yêu cầu đa dạng của người dùng đặt ra các tình huống khi chọn lựa các quyết định của mình. - 11 -
Phân tích, thiết kế hướng đối tượng bằng UM L Đoàn Văn Ban 2. Các hệ thống kỹ thuật (Technical Systems), những hệ thống tự động hoá sản xuất hay còn gọi là các hệ thống điều khiển các quá trình. Đó là những hệ thống nhằm xử lý và điều khiển tự động các quá trình vận hành các thiết bị kỹ thuật trong sản xuất, viễn thông, quân sự, các quá trình công nghiệp, v.v. Những hệ thống này thường phải làm việc theo phương thức xử lý thời gian thực. Về mặt kiến trúc vật lý, bên cạnh phần mềm, hệ thống này bao gồm nhiều loại thiết bị tin học đa dạng: từ các CPU phổ dụng, đến các máy tính chuyên dụng, các ôtômát lập trình được, như các bộ điều khiển logic lập trình được (Programmable Logic Controller – PLC), các đường truyền, các bộ cảm biến, các bộ chuyển đổi tín hiệu A/N hay N/A. 3. Các hệ thống nhúng thời gian thực (Embedded Real_time System). Hệ thống thực hiện trên những thiết bị cứng đơn giản và được nhúng vào các thiết bị khác như: mobile phone, hệ thống hướng dẫn lái xe ô tô, hệ thống điều khiển các dụng cụ dân dụng, v.v. Các hệ thống này thường được thực hiện lập trình ở mức thấp, và cũng thường thực hiện xử lý theo thời gian thực. Trong các hệ này, thường thiếu vắng các thiết bị ngoại vi thông dụng như màn hình, ổ đĩa cứng, v.v. 4. Phần mềm hệ thống (System Software). Những hệ thống này thiết lập nên hạ tầng kỹ thuật của các hệ thống máy tính, phục vụ cho các phần mềm ứng dụng chạy trên đó. Đó có thể là hệ điều hành, hệ quản trị CSDL, chương trình dịch, giao diện phần mềm ứng dụng API (Application Programming Interface), v.v. Chúng khai thác các dịch vụ tầng thấp của các phần cứng để đưa các giao diện, các dịch vụ ở tầng cao ở mức khái quát, dễ sử dụng cho các chương trình ứng dụng. 5. Các hệ thống tự động hoá văn phòng (Automated Office Ssystems). Tự động hoá văn phòng là cách tiếp cận nhằm đưa máy tính vào hoạt động văn phòng, cho phép thâu tóm mọi công việc tính toán, giao lưu, quản lý thông tin, tất cả vào trong các cửa sổ trên màn hình máy tính, có ngay trên bàn làm việc của mỗi nhân viên văn phòng. Một hệ thống tự động hoá văn phòng phải cung cấp được ít nhất một số trong các chức năng chính như sau: Thư tín điện tử (E-mail): nhận/gửi các thông điệp văn bản (Text messages) tới các cá nhân hay nhóm người. Lịch biểu, kế hoạch công tác, thông báo, v.v. Xử lý văn bản: soạn thảo, sửa chữa, mi trang, v.v. các tài liệu, biểu đồ, văn tự và đồ hoạ. Hội thảo điện tử: hội thảo nghe nhìn từ xa, trao đổi dữ liệu, các cuộc toạ đàm hỗn hợp dữ liệu và tiếng nói, hình ảnh, nối ghép các màn hình với nhau. - 12 -
Phân tích, thiết kế hướng đối tượng bằng UM L Đoàn Văn Ban Các hệ thống tích hợp điện thoại với xử lý, tính toán của máy tính: người sử dụng có thể truy cập tới các hệ CSDL thông qua hệ thống điện thoại (kể cả điện thoại không dây) để có được những dịch vụ cần thiết. Thông thường, mỗi loại phần mềm thường có những phương pháp, mô hình, công cụ và qui trình riêng. Do vậy, khi xây dựng một hệ thống phần mềm chúng ta cần phải xác định xem nó thuộc loại nào để quyết định lưa chọn giải pháp cho thích hợp và hiệu quả nhất. 1.3. Sự phát triển hệ thống Mọi hệ thống (phần mềm) đều phải trải qua sự khởi đầu, triển khai, xây dựng, kiểm định, khai thác, bảo trì và kết thúc. Gọi quá trình đó là vòng đời hay chỉ nhấn mạng đến sự triển khai và xây dựng, thì gọi là sự phát triển của hệ thống (System Develoment). Để xem xét xự phát triển hệ thống, có hai khía cạnh phải đề cập: Sự nối tiếp các giai đoạn trong quá trình phát triển hệ thống, còn gọi là chu trình phát triển hệ thống, Các phương tiện để nhận thức và đặc tả hệ thống, còn gọi là các mô hình. 1.3.1 Chu trình phát triển hệ thống Có nhiều loại chu trình phát triển phần mềm khác nhau. Ivan Sommerville [19 ] nói tới năm loại chu trình phát triển chính. (i) Mô hình thác nước (Waterfall). Đây là chu trình phát triển đầu tiên, được Royce đề xuất năm 1970 để mô tả sự phát triển hệ thống tin học. Quá trình phần mềm được chia thành dãy các giai đoạn (các pha) liên tiếp từ phân tích yêu cầu, phân tích các thành phần, thiết kế, lập trình đến thử nghiệm và triển khai hệ thống. Giai đoạn sau chỉ được bắt đầu khi giai đoạn trước đã hoàn thành (không được chờm lên nhau). Vì vậy chu trình phát triển này còn được gọi là chu trình tuyến tính (Hình 1.1). Mô hình này được thiết lập theo cách tiếp cận hướng chức năng và phù hợp cho những dự án lớn, phức tạp. Nhược điểm chính của chu trình phát triển thác nước là ở chỗ không có sự quay lui. Sự quay lui là một nhu cầu rất tự nhiên trong quá trình phát triển phần mềm, vì nhiều khi thực hiện ở giai sau người ta mới phát hiện ra những thiếu sót của giai đoạn trước và do vậy cần phải quay lại giai đoạn đó để chỉnh sửa, bổ sung cho đầy đủ. Ngoài ra, trong quá trình phát triển phần mềm theo chu trình thác nước, không có sự tham gia trực tiếp của người dùng trong mỗi giai đoạn, mà chỉ tiếp xúc với hệ thống sau khi nó đã được hoàn thành. - 13 -
Phân tích, thiết kế hướng đối tượng bằng UM L Đoàn Văn Ban Xác định bài toán và đặctả các yêu cầu Phân tích Thiết kế Mã hoá, lập trình Kiểm định Khai thác và bảo trì Hình 1.1: Chu trình thác nước Chính vì vậy mà đã có nhiều phương pháp cải tiến chu trình thác nước, cho phép sự quay lui. Chẳng hạn chu trình phát triển hình chữ V [35], được AFCIQ (Association Française pour le Contrôle Industriel de la Qualité) đề nghị bao gồm cả các bước quay lui, và ngoài ra còn đặt tương ứng các pha kiểm thử, tích hợp trong giai đoạn phân tích và thiết kế. Khi một sai sót được phát hiện thì giai đoạn đó được xem lại và chu trình bắt đầu lại từ đó. (ii) Chu trình tăng trưởng. Chu trình tăng trưởng, do D. R. Graham đề xuất năm 1989, dựa trên các bước tăng trưởng dần, cho phép hoàn thành hệ thống từng phần một. Mỗi bước tăng trưởng thực hiện một tiến trình tuyến tính gồm các bước phân tích, thiết kế, lập trình, kiểm định và chuyển giao từng phần (Hình 1.2). Quá trình này lặp lại nhiều lần cho đến khi có được phương án hoàn chỉnh cho cả hệ thống. Tăng trưởng 1 Phân tích Thiết kế Lập trình Kiểm định Chuyển giao phần 1 Tăng trưởng 2 Phân tích Thiết kế Lập trình Kiểm định Chuyển giao phần 2 . . . Hình 1.2: Chu trình phát triển phần mềm tăng trưởng Rõ ràng cách làm này chỉ thích hợp với các hệ thống có thể chia cắt và chuyển giao theo từng phần. (iii) Chu trình xoắn ốc. Chu trình xoắn ốc hay chu trình lặp được Boëhm đề xuất năm 1988, với các đặc điểm sau: - 14 -
Phân tích, thiết kế hướng đối tượng bằng UM L Đoàn Văn Ban Tiến trình lặp lại một dãy các giai đoạn nhất định, Qua mỗi vòng lặp, tạo ra một nguyên mẫu và được hoàn thiện dần, Nhấn mạnh sự khắc phục các nguy cơ, những rủi ro có thể xuất hiện trong quá trình phát triển phần mềm, trong đó có nguy cơ bắt nguồn từ các sai sót trong đặc tả yêu cầu. Trong tin học, phần mềm nguyên mẫu (Prototype) là một hệ thống: Có khả năng làm việc được trên các dữ liệu thực, nghĩa là nó đã vượt qua giai đoạn dự án trên giấy, và như vậy có thể được đánh giá bởi người thiết kế hoặc người sử dụng (khách hàng). Có thể được phát triển thêm để tiến tới hệ thống hoàn chỉnh, hoặc có thể làm cơ sở để phát triển hệ thống theo đơn đặt hàng. Được tạo lập nhanh và ít tốn kém. Dùng để kiểm chứng các giả định về nhu cầu cần đáp ứng, các lược đồ thiết kế về logic của các chương trình. Như vậy, việc tạo ra các nguyên mẫu nhanh chóng là có ích trên nhiều phương diện: Chính xác hoá các yêu cầu của hệ thống. Thường thì các nhu cầu của người dùng không được phát biểu rành mạch, khó mà đặc tả được một cách hoàn toàn đúng đắn. Một nguyên mẫu sẽ phô diễn cụ thể, tường minh để người dùng nhìn và cảm nhận thấy nó có đáp ứng trúng nhu cầu của mình hay không. Phát hiện được các hành vi lệch lạc, các sai sót. Trong thiết kế, có những điểm rất nhạy cảm, người thiết kế không lường hết được mọi tình huống. Xây dựng nguyên mẫu giúp ta có thể phát hiện được hành vi lệch lạc, các khiếm khuyết của hệ thống. Đánh giá được hiệu năng của hệ thống. Hiệu năng của hệ thống liên quan chặt chẽ tới sự thích ứng của ngôn ngữ lập trình, các nền (Platform) và các phần cứng như máy tính. Nguyên mẫu phản ánh hiệu năng tương đối của chương trình và thông qua nguyên mẫu ta có thể phát hiện được những nguyên nhân cơ bản của sự chậm chạp từ bên trong chương trình, từ những khâu giao tiếp người/máy, v.v. Kỹ thuật làm nguyên mẫu ngày nay được thực hiện được khá hiệu quả là nhờ các ngôn ngữ lập trình phi thủ tục, còn được gọi là ngôn ngữ thế hệ thứ tư, trong đó có các ngôn ngữ hướng đối tượng. Hầu hết các sản phẩm phần mềm của Viêt Nam, trong đó các phần mềm phục vụ chương trình cải cách hành chính của Chính Phủ cũng được xây dựng theo kỹ thuật làm nguyên mẫu của chu trình xoắn ốc. Ban điều hành Đề án 112 tổ chức và quản lý thực hiện rất - 15 -
Phân tích, thiết kế hướng đối tượng bằng UM L Đoàn Văn Ban chặt chẽ theo các giai đoạn, luôn có trao đổi, thảo luận, đánh giá những kết quả đạt được và trên cơ sở đó đề ra những tài liệu mẫu [37, 38, 39] để hướng dẫn các nhóm thực hiện nhằm đảm bảo phần mềm làm ra đúng theo yêu cầu. Với việc làm nguyên mẫu thì quá trình phát triển phần mềm sẽ có nhiều khác biệt so với quá trình tuyến tính nêu trên. Theo Jekins, Milton và Naumann (Đại học Indiana City), chu trình xoắn ốc có thể chia thành bốn giai đoạn cho mỗi vòng lặp chính như hình 1.3. Xác định mục tiêu, Đánh giá các phương án và các phương án ràng buộc Thử nghiệm và đánh Thiết kế và tạo giá nguyên mẫu lập nguyên mẫu Hình 1.3: Chu trình xoắn ốc Giai đoạn 1: Với vòng lặp đầu tiên thì giai đoạn này nhằm phát hiện các yêu cầu cơ bản, rõ nét nhất thông qua các phương pháp thông thường như: khảo sát, phỏng vấn, xem xét tài liệu, v.v. Không cần phải vét cạn các yêu cầu mà nhanh chóng chuyển sang giai đoạn sau. Từ vòng lặp thứ hai, thì giai đoạn này tập trung xác định các mục tiêu của vòng lặp hiện tại, các phương án và các ràng buộc từ kết quả vòng lặp trước. Giai đoạn 2: Đánh giá các phương án có thể, phát hiện ngay các nguy cơ tiềm ẩn và tìm cách giải quyết chúng. Các nguy cơ, rủi ro có thể xuất phát từ phía những công nghệ mới, những đối tác cạnh tranh, từ thị trường và khách hàng, từ phía ngân sách, tài chính, v.v., trên cơ sở đó đánh giá tính khả thi của dự án. Giai đoạn 3: Thiết kế và tạo lập nguyên mẫu, tập trung vào những điều cốt yếu. Giai đoạn 4: Thử nghiệm nguyên mẫu. Trước hết giới thiệu nó cho một số người dùng chọn lọc, thu thập các phê phán, các góp ý của họ. Tuỳ theo mức độ quan trọng, một số điều chỉnh được thực hiện ở những vòng tiếp sau. Các vòng lặp được tiếp tục cho đến khi xét thấy nguyên mẫu là tốt thì có thể chuyển sang sản xuất thực sự. Một số người cho rằng cách làm vòng vo này sẽ làm kéo dài thời gian. Song, những nghiên cứu nghiêm túc của Boëhm và Gray cho thấy thời gian có thể rút xuống còn khoảng 45% so với cách làm cũ. - 16 -
Phân tích, thiết kế hướng đối tượng bằng UM L Đoàn Văn Ban Nhưng, sự thành công của tiến trình lặp có thể dẫn tới một vài hậu quả cần dè chừng. Người dùng có thể thoả mãn với những phương án đầu và muốn dừng ngay, mặc dù không phải là không có những việc đáng làm. Việc làm tư liệu, vốn rất cần thiết cho sự hoạt động và bảo trì hệ thống sau này, cũng dễ bị bỏ qua hoặc xem nhẹ. Tóm lại, khuôn cảnh chung của kỹ nghệ phần mềm có thể được mô tả như sau: Tập hợp các yêu cầu Phân tích có Làm bản Phân tích hướng Mô hình cấu trúc mẫu 1 đối tượng xoắn ốc Thiết kế có . . . Thiết kế hướng . . . cấu trúc đối tượng L ập trình có Làm bản Lập trình hướng Mẫu hình cấu trúc mẫu n đối tượng vòng thứ n Lập trình hướng đối tượng Ki ểm định Hệ thống hoạt động Bảo trì Hình 1.4: Quá trình phát triển phần mềm Các giai đoạn của quá trình phát triển phần mềm có thể thực hiện theo những phương pháp khác nhau tuỳ thuộc vào khả năng của nhóm thực hiện dự án. Tuy nhiên, để cho thống nhất và hiệu quả thì tốt nhất là nên chọn một phương pháp, phương pháp hướng chức năng hay hướng đối tượng cho cả quá trình phát triển phần mềm. Xu thế hiện nay là nên chọn phương pháp hướng đối tượng với sự hỗ trợ của nhiều công cụ hiện đại. - 17 -
Phân tích, thiết kế hướng đối tượng bằng UM L Đoàn Văn Ban 1.3.2 Mô hình hoá hệ thống Các bước phát triển hệ thống như tìm hiểu nhu cầu, phân tích, thiết kế và lập trình hệ thống tuy có khác nhau về nhiệm vụ và mục tiêu, song chúng cùng có những đặc điểm sau: Đều phải đối mặt với sự phức tạp của các bài toán ứng dụng, Đều là quá trình nhận thức và diễn tả sự phức tạp thông qua các mô hình. Nói cách khác đều là quá trình thực hiện mô hình hoá để hiểu và xây dựng hệ thống. (i) Nguyên lý chế ngự sự phức tạp. Để tìm hiểu một thế giới vô cùng phức tạp, mọi khoa học thực nghiệm đều phải vận dụng nguyên lý “Chia để trị” (Devide and Conquer) và nguyên lý “Trừu tượng hoá”. Trừu tượng hoá (hay còn gọi là trừu xuất) là nguyên lý nhận thức, đòi hỏi phải bỏ qua những sắc thái (của một chủ đề) không liên quan tới chủ định hiện thời, để tập trung hoàn toàn vào những sắc thái liên quan đến chủ định đó (Từ điển Oxford). Nói cách khác, trước một bài toán (một chủ đề), ta tạm quyên đi hay tạm lờ đi những chi tiết có tác dụng rất ít hoặc không có tác dụng đối với lời giải bài toán, nhờ đó hình thành được một sự diễn tả đơn giản hoá và dễ hiểu, cho phép chúng ta giải quyết được bài toán thực tế, đúng theo bản chất của nó. (ii) Mô hình (Model) là một dạng trừu tượng hoá của hệ thống thực. Nói cách khác, mô hình là hình ảnh thực tại của bài toán mà chúng ta đang xét, được diễn tả ở một mức độ trừu tượng hoá nào đó, theo một quan điểm và được thể hiện bởi một hình thức (bằng văn bản, bảng biểu, biểu đồ, đồ thị, công thức hay phương trình toán học, v.v.). Ngày nay các phương pháp phân tích, thiết kế hệ thống đều có xu hướng sử dụng các mô hình được thể hiện dạng biểu đồ (diagrams). Đặc biệt phương pháp hướng đối tượng với UML, tất cả các khái niệm, các kết quả của các bước trong quá trình phát triển phần mềm đều có thể diễn tả một cách tường minh, trực quan bằng các biểu đồ [2, 3, 16] theo những ký pháp thống nhất. (iii) Mục đích của mô hình hoá. Có năm mục đích chính. 1. Mô hình giúp ta hiểu và thực hiện được sự trừu tượng, tổng quát hoá các khái niệm cơ sở để giảm thiểu độ phức tạp của hệ thống. Qua mô hình chúng ta biết được hệ thống gồm những gì? và chúng hoạt động như thế nào?. Jean Piaget từng nói: “Hiểu tức là mô hình hoá”. Do vậy, quá trình phát triển phần mềm nêu trên chẳng qua là quá trình nhận thức và diễn tả hệ thống đó. Đó cũng là quá trình thiết lập, sử dụng và biến đổi các mô hình. Có một mô hình đúng sẽ giúp ta làm sáng tỏ những vấn đề phức tạp và cho ta cái nhìn thấu đáo về vấn đề cần giải quyết. - 18 -
Phân tích, thiết kế hướng đối tượng bằng UM L Đoàn Văn Ban 2. Mô hình giúp chúng ta quan sát được hệ thống như nó vốn có trong thực tế hoặc nó phải có như ta mong muốn. Muốn hiểu và phát triển được hệ thống phần mềm theo yêu cầu thực tế thì ta phải quan sát nó theo nhiều góc nhìn khác nhau: theo chức năng sử dụng, theo các thành phần logic, theo phương diện triển khai, v.v. 3. Mô hình cho phép ta đặc tả được cấu trúc và hành vi của hệ thống để hoàn chỉnh: + Đảm bảo hệ thống đạt được mục đích đã xác định trước. Mọi mô hình đều đơn giản hoá thế giới thực, nhưng phải đảm bảo sự đơn giản đó không loại bỏ đi những những yếu tố quan trọng. + Kiểm tra được các qui định về cú pháp, ngữ nghĩa về tính chặt chẽ và đầy đủ của mô hình, khẳng định được tính đúng đắn của thiết kế, phù hợp với yêu cầu của khách hàng. Nghĩa là, mô hình hoá là quá trình hoàn thiện và tiến hoá liên tục. 4. Mô hình hoá là nhằm tạo ra khuôn mẫu (template) và hướng dẫn cách xây dựng hệ thống; cho phép thử nghiệm, mô phỏng và thực hiện theo mô hình. 5. Mô hình là cơ sở để trao đổi, ghi lại những quyết định đã thực hiện trong nhóm tham gia dự án phát triển phần mềm. Mọi quan sát, mọi sự hiểu biết (kết quả phân tích, thiết kế, lập trình) đều phải được ghi lại chi tiết để phục vụ cho cả quá trình phát triển và bảo trì hệ thống. Vì tính hiểu được của mô hình mà nó trở thành một thứ ngôn ngữ chung để trao đổi giữa những người cùng tham gia trong một dự án cũng như giữa những người phát triển phần mềm với khách hàng. Nhìn chung, không có mô hình nào là đầy đủ. Mỗi hệ thống thực tế có thể được tiếp cận thông qua một hay một số mô hình khác nhau. Quá trình mô hình hoá hệ thống phần mềm thường thực hiện theo hai cấp: + Mô hình logic: mô tả các thành phần và mối quan hệ của chúng để thực hiện các nhu cầu hệ thống, + Mô hình vật lý: xác định kiến trúc các thành phần và tổng thể của hệ thống. Tóm lại, mô hình hoá một hệ thống phải thực hiện theo cả bốn hướng: - 19 -
Phân tích, thiết kế hướng đối tượng bằng UM L Đoàn Văn Ban Kiến trúc (các thành phần) vật lý Các chức năng, Cấu trúc tĩnh (dữ nhiệm vụ hoặc quá liệu, thông tin được lưu trình xử lý các nhiệm trữ, xử lý và các yếu tố vụ của hệ thống. tạo nên hệ thống. Cách ứng xử (hành vi), Các phản ứng tức thời Hình 1.5: Các hướng mô hình hoá Có bốn yếu tố quan trọng ảnh hưởng tới hiệu quả của dự án phát triển phần mềm: 1. Con người. Yếu tố quan trọng nhất hiển nhiên là số lượng và trình độ chuyên nghiệp của những người tham gia phát triển phần mềm, những người có khả năng nắm bắt, làm chủ được những công nghệ mới, có khả năng hiểu được bài toán của lĩnh vực ứng dụng. 2. Bài toán (lĩnh vực ứng dụng). Hiệu quả của dự án phụ thuộc nhiều vào độ phức tạp của bài toán với những yêu cầu thường xuyên thay đổi, những đòi hỏi phức tạp với các ràng buộc về dữ liệu, thời gian và tài nguyên của hệ thống. 3. Công nghệ: các kỹ thuật, công cụ hỗ trợ để phát triển phần mềm, 4. Các tài nguyên: bao gồm cả các phần cứng như máy tính, thiết bị phụ trợ, phần mềm ứng dụng và tài chính, ngân sách đầu tư cho dự án phát triển phần mềm. Vấn đề rất quan trọng hiện nay trong công nghệ phần mềm là cần phải có những công cụ hỗ trợ để thực hiện mô hình hoá trực quan theo một chuẩn dễ hiểu giúp cho việc trao đổi giữa những người phát triển phần mềm hiệu quả và dễ dàng hơn. Các nhà tin học đã rất cố gắng để hình thành các công cụ thực hiện mô hình hoá trực quan. Từ những khái niệm, ký pháp quen thuộc của Booch, Ericsson, OOSE/Objectory (Jacobson), OMT (Rumbaugh) [16] người ta đã xây dựng được một ngôn ngữ mô hình hợp nhất UML [2, 3] được nhiều người chấp nhận và sử dụng như một ngôn ngữ chuẩn trong phân tích và thiết kế hệ thống phần mềm theo cách tiếp cận hướng đối tượng. Hầu hết các hãng sản xuất phần mềm lớn như: Microsoft, IBM, HP, Oracle, v.v đều sử dụng UML như là chuẩn công nghiệp phần mềm. - 20 -
Phân tích, thiết kế hướng đối tượng bằng UM L Đoàn Văn Ban 1.4 Các cách tiếp cận trong phát triển phần mềm Để thực hiện một dự án phát triển phần mềm thì vấn đề quan trọng đầu tiên chắc sẽ là phải chọn cho một cách thực hiện cho thích hợp dựa trên những yếu tố nêu trên. Có hai cách tiếp cận cơ bản để phát triển phần mềm: cách tiếp hướng chức năng (Functional-Oriented) và cách tiếp cận hướng đối tượng (Object- Oriented Approach). 1.4.1 Cách tiếp cận hướng chức năng Phần lớn các chương trình được viết bằng ngôn ngữ lập trình như C, hay Pascal từ trước đến nay đều được thực hiện theo cách tiếp cận hướng chức năng (Functional Oriented) hay còn được gọi là cách tiếp cận hướng thủ tục (Procedure-Oriented). Cách tiếp cận này có những đặc trưng sau [9, 24]: (i) Dựa vào chức năng, nhiệm vụ là chính. Khi khảo sát, phân tích một hệ thống chúng ta thường tập trung vào các nhiệm vụ mà nó cần thực hiện. Chúng ta tập trung trước hết vào việc nghiên cứu các yêu cầu của bài toán để xác định các chức năng chính của hệ thống. Ví dụ khi cần xây dựng “hệ thống quản lý thư viện” thì trước hết chúng ta thường đi nghiên cứu, khảo sát trao đổi và phỏng vấn xem những người thủ thư, bạn đọc cần phải thực hiện những công việc gì để phục vụ được bạn đọc và quản lý tốt được các tài liệu. Qua nghiên cứu “hệ thống quản lý thư viện”, chúng ta xác định được các nhiệm vụ chính của hệ thống như: quản lý bạn đọc, cho mượn sách, nhận trả sách, thông báo nhắc trả sách, v.v. Như vậy, khi đã nghiên cứu để hiểu rõ được bài toán và xác định được các yêu cầu của hệ thống thì các chức năng, nhiệm vụ của hệ thống gần như là không thay đổi suốt trong quá trình phát triển tiếp theo ngoại trừ khi cần phải khảo sát lại bài toán. Dựa chính vào chức năng (thuật toán) thì dữ liệu sẽ là phụ và biến đổi theo các chức năng. Do đó, hệ thống phần mềm được xem như là tập các chức năng, nhiệm vụ cần tổ chức thực thi. (ii) Phân rã chức năng và làm mịn dần theo cách từ trên xuống (Top/Down). Khả năng của con người là có giới hạn khi khảo sát, nghiên cứu để hiểu và thực thi những gì mà hệ thống thực tế đòi hỏi. Để thống trị (quản lý được) độ phức tạp của những vấn đề phức tạp trong thực tế thường chúng ta phải sử dụng nguyên lý chia để trị, nghĩa là phân tách nhỏ các chức năng chính thành các chức năng đơn giản hơn theo cách từ trên xuống. Qui trình này được lặp lại cho đến khi thu được những đơn thể chức năng tương đối đơn giản, hiểu được và thực hiện cài đặt chúng mà không làm tăng thêm độ phức tạp để liên kết chúng trong hệ thống. Độ phức tạp liên kết các thành phần chức năng của hệ thống thường là tỉ lệ nghịch với độ phức tạp của các đơn thể. Vì thế một vần đề đặt ra là có cách nào để biết khi nào quá trình phân tách các đơn thể chức năng hay còn gọi là quá trình làm mịn dần này kết thúc. Thông thường thì quá trình thực hiện phân rã các chức năng của hệ thống phụ thuộc nhiều vào độ phức hợp - 21 -
Phân tích, thiết kế hướng đối tượng bằng UM L Đoàn Văn Ban của bài toán ứng dụng và vào trình độ của những người tham gia phát triển phần mềm. Một hệ thống được phân tích dựa trên các chức năng hoặc quá trình sẽ được chia thành các hệ thống con và tạo ra cấu trúc phân cấp các chức năng. Chúng ta có thể khẳng định là các chức năng của hầu hết các hệ thống thông tin quản lý đều có thể tổ chức thành sơ đồ chức năng theo cấu trúc phân cấp có thứ bậc. (iii) Các đơn thể chức năng trao đổi với nhau bằng cách truyền tham số hay sử dụng dữ liệu chung. Một hệ thống phần mềm bao giờ cũng phải được xem như là một thể thống nhất, do đó các đơn thể chức năng phải có quan hệ trao đổi thống tin, dữ liệu với nhau. Trong một chương trình gồm nhiều chương trình con (thực hiện nhiều chức năng khác nhau) muốn trao đổi dữ liệu được với nhau thì nhất thiết phải sử dụng dữ liệu liệu chung hoặc liên kết với nhau bằng cách truyền tham biến. Mỗi đơn thể chức năng không những chỉ thao tác, xử lý trên những dữ liệu cục bộ (Local Data) mà còn phải sử dụng các biến chung, thường đó là các biến toàn cục (Global Data). Với việc sử dụng những biến toàn cục thì những bất lợi trong quá trình thiết kế và lập trình là khó tránh khỏi. Đối với những dự án lớn, phức tạp cần nhiều nhóm tham gia, mỗi nhóm chỉ đảm nhận một số chức năng nhất định và như thế khi một nhóm có yêu cầu thay đổi về dữ liệu chung đó sẽ kéo theo tất cả các nhóm khác có liên quan cũng phải thay đổi theo. Kết quả là khi có yêu cầu thay đổi của một đơn thể chức năng sẽ ảnh hưởng tới các chức năng khác và do đó sẽ ảnh hưởng tới hiệu xuất lao động của công việc. Mà nhu cầu thay đổi các chức năng khi phân tích là tất yếu và thường rất hay thay đổi. (iv) Tính mở (Open) và thích nghi của hệ thống được xây dựng theo cách tiếp cận này là thấp vì: • Hệ thống được xây dựng dựa vào chức năng là chính mà trong thực tế thì chức năng, nhiệm vụ của hệ thống lại hay thay đổi. Để đảm bảo cho hệ thống thực hiện được công việc theo yêu cầu, nhất là những yêu cầu về mặt chức năng đó lại bị thay đổi là công việc phức tạp và rất tốn kém. Ví dụ: giám đốc thư viện yêu cầu thay đổi cách quản lý bạn đọc hoặc hơn nữa, yêu cầu bổ sung chức năng theo dõi những tài liệu mới mà bạn đọc thường xuyên yêu cầu để đặt mua, v.v. Khi đó vấn đề bảo trì hệ thống phần mềm không phải là vấn đề dễ thực hiện. Nhiều khi có những yêu cầu thay đổi cơ bản mà việc sửa đổi không hiệu quả và vì thế đòi hỏi phải phân tích, thiết kế để xây dựng lại mới hệ thống. • Các bộ phận của hệ thống phải sử dụng biến toàn cục để trao đổi với nhau, do vậy, khả năng thay đổi, mở rộng của chúng và của cả hệ thống là bị hạn chế. Như trên đã phân tích, những thay đổi liên quan đến các dữ liệu - 22 -
Phân tích, thiết kế hướng đối tượng bằng UM L Đoàn Văn Ban chung sẽ ảnh hưởng tới tất cả các bộ phận liên quan. Do đó, một thiết kế tốt phải dễ hiểu và sửa đổi chỉ có hiệu ứng cục bộ. (v) Khả năng tái sử dụng (Reuse) bị hạn chế và hầu như không hỗ cơ chế kế thừa (Inheritance). Để có độ thích nghi tốt thì một thành phần phải là tự chứa. Muốn là tự chứa hoàn toàn thì một thành phần không nên dùng nhiều các thành phần ngoại lai. Tuy nhiên, điều này lại mâu thuẫn với kinh nghiệm nói rằng các thành phần hiện có nên là dùng lại được. Vậy là cần có một sự cân bằng giữa tính ưu việt của sự dùng lại các thành phần (ở đây chủ yếu là cấu trúc và các hàm) và sự mất mát tính thích ứng được của chúng. Các thành của hệ thống phải kết dính (Cohension) nhưng phải tương đối lỏng để dễ thích nghi. Một trong cơ chế chính hỗ trợ để dễ có được tính thích nghi là kế thừa thì cách tiếp cận hướng chức năng lại không hỗ trợ. Đó là cơ chế biểu diễn tính tương tự của các thực thể, đơn giản hoá định nghĩa những khái niệm tương tự từ những sự vật đã được định nghĩa trước trên cơ sở bổ sung hay thay đổi một số các đặc trưng hay tính chất của chúng. Cơ chế này giúp chúng ta thực hiện được nguyên lý tổng quát hoá và chi tiết hoá các thành phần của hệ thống phần mềm. 1.4.2 Cách tiếp cận hướng đối tượng Để khắc phục được những vấn đề tồn tại nêu trên thì chúng ta cần phải nghiên cứu phương pháp, mô hình và công cụ mới, thích hợp để phát triển phần mềm. Mô hình hướng đối tượng [4, 5, 10, 12, 13, 14, 18, 24, 32, 33] có thể giúp chúng ta vượt được khủng hoảng trong công nghệ phần mềm và hy vọng sẽ đưa ra được những sản phẩm phần mềm thương mại chất lượng cao: tin cậy, dễ mở rộng, dễ thích nghi, cường tráng và phù hợp với yêu cầu của khách hàng. Cách tiếp cận hướng đối tượng có những đặc trưng sau. (i) Đặt trọng tâm vào dữ liệu (thực thể). Khi khảo sát, phân tích một hệ thống chúng ta không tập trung vào các nhiệm vụ như trước đây mà tìm hiểu xem nó gồm những thực thể nào. Thực thể hay còn gọi là đối tượng, là những gì như người, vật, sự kiện, khái niệm, v.v. mà chúng ta đang quan tâm, hay cần phải xem xét và xử lý. Ví dụ, khi xây dựng “Hệ thống quản lý thư viện” thì trước hết chúng ta tìm hiểu xem nó gồm những lớp đối tượng hoặc những khái niệm nào. Đó là các lớp Sách, Tạp_Chí, Bạn_Đọc, v.v. (ii) Xem hệ thống như là tập các thực thể, các đối tượng. Để hiểu rõ về hệ thống chúng ta phân tách hệ thống thành các đơn thể đơn giản hơn. Quá trình này được lặp lại cho đến khi thu được những đơn thể tương đối đơn giản, dễ hiểu và thực hiện cài đặt chúng mà không làm tăng thêm độ phức tạp khi liên kết chúng trong hệ thống. Các đối tượng trong hệ thống liên quan với nhau theo các quan hệ: kết hợp (Association), kết nhập (Aggregation), kế thừa (Inheritance) và sự phụ thuộc (Dependency) [25, 32]. Phương pháp hướng đối tượng cho phép - 23 -
Phân tích, thiết kế hướng đối tượng bằng UM L Đoàn Văn Ban đặc tả hết được tất cả các mối quan hệ của các đối tượng đúng với bản chất tự nhiên như trong thế giới thực. (iii) Các lớp đối tượng trao đổi với nhau bằng các thông điệp (Message). Theo nghĩa thông thường thì lớp (Class) là nhóm một số người, vật có những đặc tính tương tự nhau hoặc có những hành vi ứng xử giống nhau. Trong mô hình đối tượng, khái niệm lớp là cấu trúc mô tả hợp nhất các thuộc tính (Attributes), hay dữ liệu thành phần (Data Member) thể hiện các đặc tính của mỗi đối tượng và các phương thức (Methods), hay hàm thành phần (Member Function) thao tác trên các dữ liệu riêng và là giao diện trao đổi với các đối tượng khác để xác định hành vi của chúng trong hệ thống. Khi có yêu cầu dữ liệu để thực hiện một nhiệm vụ nào đó, một đối tượng sẽ gửi một thông điệp (gọi một phương thức) cho đối tượng khác. Đối tượng nhận được thông điệp yêu cầu sẽ phải thực hiện một số công việc trên các dữ liệu mà nó sẵn có hoặc lại tiếp tục yêu cầu những đối tượng khác hỗ trợ để có những thông tin và trả lời cho đối tượng yêu cầu. Với phương thức xử lý như thế thì một chương trình hướng đối tượng thực sự có thể không cần sử dụng biến toàn cục nữa [33]. (iv) Tính mở và thích nghi của hệ thống cao hơn vì: • Hệ thống được xây dựng dựa vào các lớp đối tượng nên khi có yêu cầu thay đổi thì chỉ thay đổi những lớp đối tượng có liên quan hoặc bổ sung thêm một số lớp đối tượng mới (có thể kế thừa từ những lớp có trước) để thực thi những nhiệm vụ mới mà hệ thống cần thực hiện. Ví dụ: Giám đốc thư viện yêu cầu bổ sung chức năng theo dõi những tài liệu mới mà bạn đọc thường xuyên yêu cầu để đặt mua, ta có thể bổ sung thêm lớp mới để theo dõi yêu cầu: lớp Yêu_Cầu. • Trong các chương trình hướng đối tượng có thể không cần sử dụng biến toàn cục nên mọi sửa đổi chỉ có hiệu ứng cục bộ. (v) Hỗ trợ sử dụng lại và cơ chế kế thừa. Các lớp đối tượng được tổ chức theo nguyên lý bao gói (Encapsulation) và che giấu thông tin (Information Hidding) tăng thêm hiệu quả của kế thừa và độ tin cậy của hệ thống. Các ngôn ngữ lập trình hướng đối tượng như: C++, Java [33], C#, Delphi, v.v. đều hỗ trợ quan hệ kế thừa. Ưu điểm chính của phương pháp hướng đối tượng: • Đối tượng là cơ sở để kết hợp các đơn thể có thể sử dụng lại thành hệ thống lớn hơn, tạo ra những sản phẩm có chất lượng cao. Đây cũng là cơ sở để thực hiện theo công nghệ thành phần. • Qui ướ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 đối tượng thành phần bên trong hệ thống và những hệ thống bên ngoài trở nên dễ dàng hơn. Điều đó giúp cho việc phân chia - 24 -
Phân tích, thiết kế hướng đối tượng bằng UM L Đoàn Văn Ban những dự án lớn, phức tạp để phân tích, thiết kế theo cách chia nhỏ bài toán thành các lớp đối tượng hoàn toàn tương ứng với quan điểm hướng tới lời giải phù hợp với thế giới thực một các tự nhiên. • Nguyên lý bao gói, che giấu thông tin hỗ trợ cho việc xây dựng những hệ thống thông tin an toàn và tin cậy. • Nguyên lý kế thừa 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, không những có thể giảm thiểu được thời gian thực hiện mà còn làm cho hệ thống có tính mở, tin cậy hơn. • Phương pháp hướng đối tượng, nhất là nguyên lý kế thừa cho phép dễ dàng xác định những bộ phận cơ bản, xây dựng các lớp như là các đơn vị cơ sở của hệ thống và sử dụng ngay khi chúng mà không cần phải hoàn thiện, không đòi hỏi phải thực hiện đầy đủ tất cả các chức năng (đơn thể mở) và sau đó có thể mở rộng đần và không làm ảnh hưởng tới các đơn thể khác, không đòi hỏi phải thiết kế lại. • Định hướng đối tượng cung cấp những công cụ, môi trường mới, hiệu quả để phát triển phần mềm theo hướng công nghiệp và hỗ trợ để tận dụng được những khả năng kế thừa, sử dụng lại ở phạm vi diện rộng để xây dựng được những hệ thống phức tạp, nhạy cảm như: hệ thống động, hệ thống thời gian thực, hệ thống đa phương tiện, v,v. • Xoá bỏ được hố ngăn cách giữa các pha phân tích, thiết kế, cài đặt và kiểm định trong quá trình xây dựng phần mềm. Nhiều kết quả (sản phẩm) của các giai đoạn trước có thể sử dụng ngay ở những giai đoạn sau. Hơn nữa, để hiểu rõ về những vấn đề cần mô hình hoá thì ngoài những khái niệm cơ sở của phương pháp luận thì cần phải hiểu rõ các tính chất, những đặc trưng của những hệ thống, phương pháp đó. Với mục đích đó, chúng ta có thể tìm hiểu thêm một số kết quả nghiên cứu về những khả năng đặc tả và việc xử lý thông tin của các hệ thống [23, 31, 36], tập trung vào các hệ thống hướng đối tượng, nghiên cứu các hành vi, các tính chất đảm bảo tính nhất quán thông tin của mô hình hệ thống [25, 26, 27, 28] và những vấn đề chuyển đổi tương đương giữa các mô hình dữ liệu [30, 32, 34]. 1.5. Quá trình phát triển phần mềm hợp nhất Phần mềm là một sản phẩm được phát triển hay được kỹ nghệ hoá và được chế tạo tương tự như các sản phẩm công nghiệp (phần cứng) khác. Phát triển phần mềm và chế tạo phần cứng cũng có những điểm tương đồng: đều là sản phẩm và chất lượng của chúng phụ thuộc nhiều vào thiết kế, hơn nữa lại phụ thuộc cơ bản vào con người. Tuy nhiên, phần mềm và phần cứng lại có nhiều điểm đặc trưng rất khác nhau. - 25 -
Phân tích, thiết kế hướng đối tượng bằng UM L Đoàn Văn Ban • Qui trình và phương pháp tổ chức thực hiện để sản xuất ra chúng rất khác nhau, phần cứng thường được sản xuất theo dây chuyền, hành loạt còn phần mềm thường được xây dựng theo đơn đặt hàng, đơn chiếc. • Các giai đoạn chế tạo ra phần cứng có thể xác định và có khả năng điều chỉnh được chất lượng của sản phẩm còn đối với phần mềm thì không dễ gì thay đổi được, • Mối quan hệ giữa người sử dụng và công việc cần thực hiện với từng loại sản phẩm là hoàn toàn khác nhau, • Cách tiếp cận để xây dựng, chế tạo các sản phẩm cũng khác nhau. Khả năng nhân bản của chúng là hoàn toàn trái ngược nhau. Việc bảo vệ bản quyền sản phẩm phần mềm là cực kỳ khó khăn vì khả năng sao chép thành nhiều bản giống nhau là có thể thực hiện được (tương đối dễ). • Phần mềm khác hẳn với phần cứng là không bị hư hỏng theo thời gian, không bị tác động của môi trường (thời tiết, nhiệt độ, điều kiện, v.v ). Do vậy, đối với phần cứng việc bảo hành là đảm bảo nó hoạt động được như mới còn đối với phần mềm thì lại khác hẳn. Bảo hành, bảo trì phần mềm là bảo đảm cho hệ thống hoạt động đúng với thiết kế và đáp ứng yêu cầu sử dụng của khách hàng. Chính vì thế mà công bảo hành phần mềm là rất tốn kém và đòi hỏi phải tập trung nhiều hơn vào khâu phân tích, thiết kế hệ thống. Mọi hệ thống phần mềm cũng như các hệ thống khác không thể tồn tại độc lập mà nó luôn vận động và tồn tại trong một môi trường, tương tác với thế giới xung quanh. Một hệ thống có thể xem như là hệ thống con của một hệ thống khác và bản thân nó lại có thể chứa một số các hệ thống con khác nhỏ hơn. Công nghệ phần cứng phát triển nhanh cả về chất lượng và tốc độ xử lý với giá thành ngày một hạ trong khi giá phần mềm lại rất cao. Để phát triển được những hệ thống phần mềm đáp ứng được những yêu cầu trên thì đòi hỏi phải áp dụng lý thuyết, kỹ nghệ, phương pháp và công cụ mới để tạo ra một qui trình phát triển phần mềm hợp nhất. Công nghệ phần mềm (CNPM) là đề cập đến các lý thuyết, phương pháp luận và các công cụ cần thiết để phát triển phần mềm. Mục đích của CNPM là làm ra những phần mềm chất lượng cao, tin cậy với một hạn chế về nguồn lực, theo đúng một lịch trình đặt trước, phù hợp với ngân sách dự kiến và đáp ứng các yêu cầu người dùng. Hơn nữa, CNPM không chỉ là phải làm ra hệ thống phần mềm mà phải làm được các hồ sơ, tài liệu như các tài liệu thiết kế, tài liệu hướng dẫn sử dụng, v.v. làm cơ sở để bảo trì và mở rộng, phát triển hệ thống sau này. Tóm lại, để xây dựng được những hệ thống phần mềm đáp ứng những yêu cầu trên, chúng ta cần phải: - 26 -
Phân tích, thiết kế hướng đối tượng bằng UM L Đoàn Văn Ban • Có một qui trình phát triển phần mềm thống nhất gồm các bước thực hiện rõ ràng, mà sau mỗi bước đều phải có các sản phẩm cụ thể; • Có các phương pháp và kỹ nghệ phù hợp với từng giai đoạn thực hiện phát triển phần mềm; • Có công cụ để làm ra sản phẩm phần mềm theo yêu cầu. Quá trình phát triển một sản phẩm (Software Development Process) là quá trình định nghĩa ai làm cái gì, làm khi nào và như thế nào. Quá trình xây dựng một sản phẩm phần mềm hoặc nâng cấp một sản phẩm đã có được gọi là quá trình phát triển phần. Hệ thống phần mềm được kiến tạo là sản phẩm của một loạt các hoạt động sáng tạo và có quá trình phát triển. Quá trình phát triển những phần mềm phức tạp phải có nhiều người tham gia thực hiện. Trước hết đó là khách hàng và những nhà đầu tư, đó là những người đưa ra vấn đề cần giải quyết trên máy tính. Những người phát triển hệ thống gồm các nhà phân tích, thiết kế và lập trình làm nhiệm vụ phân tích các yêu cầu của khách hàng, thiết kế các thành phần của hệ thống và thực thi cài đặt chúng. Sau đó phần mềm được kiểm thử và triển khai ứng dụng để thực thi những vấn đề mà người sử dụng yêu cầu. Quá trình phát triển phần mềm được xác định thông qua tập các hoạt động cần thực hiện để chuyển đổi các yêu cầu của khách hàng (người sử dụng) thành hệ thống phần mềm. Có sáu bước chính cần thực hiện trong quá trình phát triển phần mềm: 1. Xác định và đặc tả các yêu cầu 2. Phân tích hệ thống 3. Thiết kế hệ thống 4. Lập trình, mã hoá chương trình 5. Kiểm định hệ thống 6. Vận hành và bảo trì hệ thống. Có thể thực hiện các bước trên theo nhiều phương pháp khác nhau. Theo đó, số các bước đề xuất của các phương pháp cũng có thể khác nhau. Các dự án có thể thực hiện theo những mô hình khác nhau như mô hình "thác nước", mô hình "tạo nguyên mẫu", mô hình "xoắn ốc", v.v. tuỳ thuộc vào từng lĩnh vực ứng dụng và khả năng thực hiện của các nhóm tham gia thực hiện dự án. (i) Xác định các yêu cầu và phân tích hệ thống Từ các yêu cầu của khách hàng, chúng ta xác định được các mục tiêu của phần mềm cần phát triển. Thường đó là các yêu cầu chức năng về những gì mà hệ thống phải thực hiện, nhưng chưa cần chỉ ra các chức năng đó thực hiện như - 27 -
Phân tích, thiết kế hướng đối tượng bằng UM L Đoàn Văn Ban thế nào. Việc xác định đúng và đầy đủ các yêu cầu của bài toán là nhiệm vụ rất quan trọng, nó làm cơ sở cho tất cả các bước tiếp theo trong dự án phát triển phần mềm. Muốn vậy, thì phải thực hiện đặc tả chi tiết các yêu cầu của hệ thống. UML cung cấp biểu đồ ca sử dụng để đặc tả các yêu cầu của hệ thống. Tài liệu đặc tả các yêu cầu được sử dụng để: Làm cơ sở để trao đổi với người sử dụng, để thảo luận giữa các nhóm thành viên trong dự án phát triển phần mềm về những gì mà hệ thống sẽ phải thực hiện (và cả những gì nó không cần thực hiện). Làm căn cứ cơ bản để kiểm tra, thử nghiệm trong các bước tiếp theo của quá trình phát triển phần mềm. Muốn đạt được các mục tiêu trên thì quá trình phải thực hiện: Xác định và hiểu rõ miền, phạm vi của bài toán: Những người phát triển sẽ xây dựng hệ thống theo sự hiểu biết của họ như thế nào về những yêu cầu của khách hàng và những khái niệm cơ sở của bài toán ứng dụng. Nắm bắt các yêu cầu: Người phân tích phải nắm bắt được tất cả các nhu cầu của khách hàng bằng cách phải trao đổi với mọi người có liên quan đến dự án, tham khảo các tài liệu liên quan. Thông qua việc thảo luận, trao đổi với khách hàng, các chuyên gia của lĩnh vực ứng dụng và những người đã, đang sử dụng những hệ thống có sẵn, ta có thể phát hiện và nắm bắt được các yêu cầu của họ. Phương pháp trừu tượng hoá giúp ta dễ dàng nắm bắt được các yêu cầu của hệ thống. Phân loại: Vấn đề quan trọng nhất trong giai đoạn này là phải hiểu rõ các yêu cầu đã được xác định. Muốn vậy, ta phải tìm cách phân loại chúng theo tầm quan trọng, hay chức năng chính của những người sử dụng và của khách hàng. Thẩm định: Kiểm tra xem các yêu cầu có thống nhất với nhau và đầy đủ không, đồng thời tìm cách giải quyết các mối mâu thuẫn giữa các yêu cầu nếu có. Nghiên cứu tính khả thi: Tính khả thi của một dự án tin học phải được thực hiện dựa trên các yếu tố bao gồm các khía cạnh tài chính, chiến lược, thị trường, con người, đối tác, kỹ thuật, công nghệ và phương pháp mô hình hoá, v.v. Nói chung, không có một qui tắc hướng dẫn cụ thể để biết khi nào công việc phân tích các yêu cầu sẽ kết thúc và quá trình phát triển có thể chuyển sang bước tiếp theo. Nhưng có thể dựa vào các câu trả lời cho những câu hỏi sau để chuyển sang bước tiếp theo. Khách hàng, người sử dụng (NSD) và những người phát triển đã hiểu hoàn toàn hệ thống chưa? Đã nêu được đầy đủ các yêu cầu về chức năng (dịch vụ), đầu vào / ra và những dữ liệu cần thiết chưa? - 28 -
Phân tích, thiết kế hướng đối tượng bằng UM L Đoàn Văn Ban Bức tranh chung trong pha phân tích các yêu cầu của hệ thống có thể mô tả như trong hình 1.6. Người phát triển hệ thống Hiểu rõ Nắm bắt các yêu cầu các yêu cầu Khách hàng, Nghiên cứu Mô tả tính khả thi các yêu cầu Các chuyên gia hệ thống Thẩm Phân loại định Người sử dụng Tài liệu đặc tả yêu cầu (NSD) và bước tiếp theo Hình 1.6: Mối quan hệ giữa các công việc trong pha phân tích các yêu cầu Vấn đề xác định đúng và đầy đủ các yêu cầu của hệ thống là rất quan trọng, nó ảnh hưởng rất lớn tới chất lượng của sản phẩn sau này. Theo Finkelstein (1989) khi khảo sát, đánh giá về các pha thực hiện trong quá trình phát triển phần mềm thì trên 55% [19] các lỗi của phần mềm là do các yêu cầu của hệ thống chưa được phát hiện đầy đủ và chi phí cho việc sửa các lỗi đó ( để bảo trì hệ thống) chiếm tới trên 80% chi phí của cả dự án. (ii) Phân tích hệ thống hướng đối tượng Phân tích hướng đối tượng (OOA): là một giai đoạn của quá trình phát triển phần mềm, trong đó mô hình khái niệm được mô tả chính xác, súc tích thông qua các đối tượng thực và các khái niệm của bài toán ứng dụng. Phân tích hướng đối tượng vừa là ngành khoa học vừa là nghệ thuật nên để xây dựng được những hệ thống tốt, tráng kiện, có tính mở và dễ bảo trì thì ta phải biết vận dụng các nguyên lý, phương pháp khoa học kết hợp được cả heuristic và các mẫu thử nghiệm để nhanh chóng tích luỹ và hoàn thiện kỹ năng phân tích, thiết kế của mình. Thông qua việc áp dụng các nguyên lý và kinh nghiệm thực hiện theo mẫu hướng dẫn [10] chúng ta nhanh chóng học được cách tạo ra các thiết kế hệ thống phần mềm tốt hơn. Phân tích hướng đối tượng tập trung vào việc tìm kiếm các đối tượng, khái niệm trong lĩnh vực bài toán và xác định mối quan hệ của chúng trong hệ thống. - 29 -
Phân tích, thiết kế hướng đối tượng bằng UM L Đoàn Văn Ban Nhiệm vụ của người phân tích là nghiên cứu kỹ các yêu cầu của hệ thống và phân tích các thành phần của hệ thống cùng các mối quan hệ của chúng. Trong khâu phân tích hệ thống chủ yếu trả lời câu hỏi: Hệ thống gồm những thành phần, bộ phận nào? Hệ thống cần thực hiện những cái gì? Kết quả chính của pha phân tích hệ thống hướng đối tượng là biểu đồ lớp, biểu đồ trạng thái, biểu đồ trình tự, biểu đồ cộng tác và biểu đồ thành phần. (iii) Thiết kế hệ thống hướng đối tượng Dựa vào các đặc tả yêu cầu và các kết quả phân tích (các biểu đồ nêu trên) để thiết kế hệ thống. Thiết kế hướng đối tượng (OOD) là một giai đoạn trong quá trình phát triển phần mềm, trong đó hệ thống được tổ chức thành tập các đối tượng tương tác với nhau và mô tả được cách để hệ thống thực thi nhiệm vụ của bài toán ứng dụng. Trong khâu thiết kế hệ thống hướng đối tượng chủ yếu trả lời câu hỏi làm như thế nào? và Trong hệ thống có những lớp đối tượng nào, trách nhiệm của chúng là gì? Các đối tượng tương tác với nhau như thế nào? Các nhiệm vụ mà mỗi lớp đối tượng phải thực hiện là gì? Dữ liệu nghiệp vụ và các giao diện được xây dựng như thế nào? Kiến trúc và cấu hình của hệ thống? Nhiệm vụ chính của thiết kế hệ thống là: Xây dựng các thiết kế chi tiết mô tả các thành phần của hệ thống ở mức cao hơn khâu phân tích, thiết kế giao diện để phục vụ cho việc cài đặt. Nghĩa là, các lớp đối tượng được định nghĩa chi tiết gồm đầy đủ các thuộc tính, các thao tác phục vụ cho việc cài đặt bằng ngôn ngữ lập trình hướng đối tượng được lựa chọn ở các bước sau. Đồng thời đưa ra được kiến trúc (là trọng tâm) của hệ thống để đảm bảo cho hệ thống có thể thay đổi, có tính mở, dễ bảo trì, thân thiện với NSD, v.v. Nghĩa là tổ chức các lớp thành các gói hoặc các hệ thống con theo một kiến trúc phù hợp với nhu cầu phát triển của công nghệ (mạng, phân tán, v.v.) đồng thời phù hợp với xu thế phát triển của lĩnh vực ứng dụng. Thiết kế CSDL, có thể chọn mô hình quan hệ hay mô hình đối tượng. Bởi vì tồn tại nhiều mô hình dữ liệu khác nhau, nên khi xây dựng hệ thống phần mềm lớn chúng ta phải thiết kế các phương án tích hợp dữ - 30 -
Phân tích, thiết kế hướng đối tượng bằng UM L Đoàn Văn Ban liệu từ nhiều nguồn khác nhau, nghĩa là những khả năng chuyển đổi, kết hợp các mô hình dữ liệu đó với nhau. Những kết quả trên được thể hiện trong các biểu đồ: biểu đồ lớp (chi tiết), biểu đồ hành động, biểu đồ thành phần và biểu đồ triển khai. Tất cả các kết quả thiết kế phải được ghi lại thành các hồ sơ, tài liệu cho hệ thống. Trong các tài liệu thiết kế phải mô tả cụ thể những thành phần nào, làm những gì và làm như thế nào. Mô hình khái niệm, Kiến trúc chi tiết, cụ thể và Đặc tả các yêu cầu phụ thuộc vào vài đặt: khung của hệ thống Kiến trúc tổng quát và Thiết kế logic: trừu tượng hoá Thiết kế chi tiết: Phân chia các thành phần, Làm mịn dần các thành phần, Nhiệm vụ các thành phần Cách thực hiện của mỗi thành phần Hình 1.7: Thiết kế logic và thiết kế chi tiết (iv) Lập trình hướng đối tượng Trong giai đoạn này, mỗi thành phần đã được thiết kế sẽ được lập trình bằng ngôn ngữ lập trình hướng đối tượng được lựa chọn thành những mô đun chương trình (chương trình con). Mỗi mô đun này sẽ được kiểm định hoặc thử nghiệm theo các tài liệu đặc tả của giai đoạn thiết kế. Công việc này được mô tả như sau: Tập các mô đun Đặc tả thiết kế Lập trình chương trình (Xây dựng các lớp) Hình 1.8: Lập trình tập trung xây dựng lớp Hiện nay có một số công cụ hỗ trợ cho quá trình phân tích, thiết kế và có thể sinh mã tự động cho những thành phần chính của mô hình như: Rose [8, 22], hay Visual Studio .NET của Microsoft, v.v. (v) Kiểm định phần mềm Các mô đun chương trình cần phải được kiểm định và sau đó được tích hợp với nhau thành hệ thống tổng thể. Chúng phải được kiểm tra xem có đáp ứng được các yêu cầu của khách hàng hay không. Kiểm thử phần mềm là một quá trình liên tục, xuyên suốt mọi giai đoạn trong quá trình phát triển nhằm đảm bảo rằng phần mềm thoả mãn các yêu cầu thiết kế, thẩm định xem những yêu cầu đó - 31 -
Phân tích, thiết kế hướng đối tượng bằng UM L Đoàn Văn Ban có đáp ứng các nhu cầu của người dùng hay không. Kiểm thử chương trình đồng nghĩa với việc tìm ra những lỗi chưa được phát hiện, chứ không thể chứng minh được là chương trình đó đúng đắn. Có hai kỹ thuật kiểm định phần mềm chính [1]: kỹ thuật “Hộp đen” (Black Box) và kỹ thuật “Hộp trắng” (White Box). Kỹ thuật kiểm thử “Hộp đen” còn được gọi là kỹ thuật hướng dữ liệu vào/ra. Nó được sử dụng để kiểm tra các đặc tả chức năng của thiết kế và không quan tâm đến cấu trúc bên trong của hệ thống. Nếu các đầu ra (kết quả) không đúng như mong muốn thì kiểm thử thành công trong việc phát hiện được lỗi phần mềm. Còn kỹ thuật “Hộp trắng” lại đòi hỏi hiểu biết về cầu trúc logic bên trong, các cấu trúc điều khiển và các luồng dữ liệu của chương trình. Hai kỹ thuật này không thay thế được nhau mà bổ sung cho nhau. Kiểm thử hộp trắng có thể làm sáng tỏ các lỗi tìm thấy trong kiểm thử hộp đen bởi vì chúng xem xét phần mềm thông qua việc nghiên cứu cấu trúc của chương trình đó. Vấn đề kiểm định phần mềm đang là thách thức lớn cho các công ty phần mềm của Việt Nam. (vi) Vận hành, khai thác và bảo trì hệ thống Giai đoạn tiếp theo bắt đầu bằng việc cài đặt hệ thống phần mềm trong môi trường sử dụng của khách hàng sau khi sản phẩm đã được kiểm định và giao cho họ. Hệ thống sẽ hoạt động, cung cấp các thông tin, xử lý các yêu cầu và thực hiện những gì đã được thiết kế. Tuy nhiên, vấn đề bảo trì phần mềm hoàn toàn khác với bảo trì của phần cứng. Như đã phân tích ở trên, bảo trì phần mềm là đảm bảo cho hệ thống hoạt động đáp ứng được các yêu cầu của NSD, của khách hàng. Mà các yêu cầu này trong thực tế lại hay thay đổi, do vậy công tác bảo trì lại bao gồm cả những sự thay đổi hệ thống sao cho nó phù hợp với yêu cầu hiện tại của họ, thậm chí có những thay đổi chưa phát hiện được trong các pha phân tích, thiết kế. Nghĩa là, hệ thống phần mềm phải được nâng cấp, hoàn thiện liên tục và chi phí cho công tác bảo trì là khá tốn kém. Thông thường, có hai loại nâng cấp: Nâng cao hiệu quả của hệ thống: bao gồm những thay đổi mà khách hàng cho là sẽ cải thiện hiệu quả công việc của hệ thống, như bổ sung thêm các chức năng hay giảm thời gian xử lý, trả lời của hệ thống, v.v. Đảm bảo sự thích nghi đối với sự thay đổi môi trường của hệ thống hay sự sửa đổi cho phù hợp với những thay đổi của chính sách, qui chế mới ban hành của Chính phủ. Một cách tổng quát, quá trình phát triển phần mềm với UML được thực hiện thống nhất dựa trên các bước xây dựng các biểu đồ mô tả các yêu cầu, khái niệm, sự tương tác và kiến trúc của hệ thống. - 32 -
Phân tích, thiết kế hướng đối tượng bằng UM L Đoàn Văn Ban 1.6. Kết luận Ngày nay phương pháp hướng đối tượng đang được tập trung nghiên cứu và triển khai ứng dụng rộng rãi để tạo ra những phần mềm có tính mở, dễ thay đổi theo yêu cầu của khách hàng, đáp ứng được các tiêu chuẩn phần mềm chất lượng cao theo yêu cầu của nền công nghệ thông tin hiện đại. Một điều rất quan trọng trong công nghệ phần mềm là các khái niệm mới của mô hình hệ thống hướng đối tượng, các bước phát triển có thể đặc tả và thực hiện theo một qui trình hợp nhất với một hệ thống ký hiệu chuẩn đó là ngôn ngữ mô hình hoá hợp nhất UML. Mặc dù phương pháp hướng đối tượng có những ưu việt như đã phân tích, song còn có những vấn đề tồn tại về mặt mô hình hình thức hướng đối tượng. Phương pháp này chưa có một mô hình lý thuyết phù hợp (đủ đơn giản để cài đặt) cho các đối tượng, trong đó có thể thực hiện được các phép toán trên đối tượng giống như đối với mô hình quan hệ. Tương tự, vấn đề về quản trị CSDL đối tượng cũng còn là một thách thức lớn đối với ngành CNTT. Việc tổ chức, xử lý và quản lý đối tượng sao cho đảm bảo tính nhất quán dữ liệu trong hệ thống, đặc biệt việc truy vấn đối tượng như thế nào để cho hiệu quả nhất luôn là những vấn đề mở, cần phải được tập trung nghiên cứu. Câu hỏi và bài tập 1.1 Hệ thống phần mềm là gì?, nêu các đặc trưng cơ bản của sản phẩm phần mềm? 1.2 Vai trò và mục đích của mô hình hoá trong quá trình phát triển phần mềm? 1.3 Tại sao lại cần phải có một qui trình phát triển phần mềm thống nhất? 1.4 Phân tích các đặc trưng cơ bản của cách tiếp cận hướng chức năng và hướng đối tượng trong quá trình phát triển phần mềm. 1.5 Nêu những mô hình cơ bản được ứng dụng để phát triển hệ thống hiện nay? 1.6 Chọn từ danh sách dưới đây những thuật ngữ thích hợp để điền vào các chỗ [( )] trong đoạn văn mô tả về hệ thống phần mềm. Hệ thống phần mềm hay gọi tắt là hệ thống, là tổ hợp các [(1)], [(2)] có quan hệ qua lại với nhau, [(3)] thông qua việc nhận các dữ liệu đầu vào (Input) và sản sinh ra những kết quả đầu ra (Output) thường là ở các dạng thông tin khác nhau nhờ một [(4)], biến đổi [(5)]. Chọn câu trả lời: a. cùng hoạt động hướng tới mục tiêu chung b. quá trình xử lý c. phần mềm d. có tổ chức e. phần cứng - 33 -
Phân tích, thiết kế hướng đối tượng bằng UM L Đoàn Văn Ban 1.7 Hãy chọn những thuật ngữ thích hợp nhất để điền vào các chỗ [( )] trong đoạn văn dưới đây mô tả về quá trình phân tích hướng chức năng. Để hiểu được những hệ thống lớn, phức tạp, chúng ta thường phải sử dụng nguyên lý [(1)], nghĩa là [(2)] chính thành các chức năng đơn giản hơn theo cách tiếp cận [(3)]. Qui trình này được lặp lại cho đến khi thu được những đơn thể chức năng tương đối đơn giản, dễ hiểu và thực hiện cài đặt chúng mà không làm tăng thêm độ phức tạp để liên kết chúng trong [(4)]. Chọn câu trả lời: a. từ trên xuống b. phân tách nhỏ các chức năng c. hệ thống d. chia để trị (devide and conquer) 1.8 Hãy chọn dãy các bước thực hiện trong danh sách dưới đây cho phù hợp với qui trình phát triển phần mềm theo mô hình "thác nước". (1) Xác định các yêu cầu (2) Thiết kế hệ thống (3) Cài đặt và kiểm tra hệ thống (4) Vận hành và bảo trì hệ thống (5) Phân tích hệ thống Chọn câu trả lời: a. (2) → (1)→(3)→(5)→(4) b. (1) → (2)→(3)→(4)→(5) c. (1) → (5)→(2)→(3)→(4) d. (1) → (3)→(2)→(5)→(4) - 34 -
Phân tích, thiết kế hướng đối tượng bằng UM L Đoàn Văn Ban CHƯƠNG II UML VÀ QUÁ TRÌNH PHÁT TRIỂN PHẦN MỀM Nội dung của chương II: 9 Giới thiệu tóm lược về ngôn ngữ mô hình hoá thống nhất UML 9 Các khái niệm cơ bản của phương pháp hướng đối tượng, 9 Mối quan hệ giữa các lớp đối tượng, 9 Quá trình phát triển phần mềm. Để xây dựng được một sản phẩm phần mềm tốt, đương nhiên là cần một phương pháp phù hợp. Phương pháp phát triển phù hợp là sự kết hợp của ba yếu tố: (i) Một tập hợp các khái niệm và mô hình, bao gồm các khái niệm cơ bản sử dụng trong phương pháp cùng với cách biểu diễn chúng (thường là dưới dạng đồ thị, biểu đồ). (ii) Một quá trình phát triển, bao gồm các bước thực hiện lần lượt, các hoạt động cần thiết. (iii) Một công cụ mạnh trợ giúp cho việc triển khai hệ thống chặt chẽ và nhanh chóng. UML là ngôn ngữ chuẩn giúp chúng ta thể hiện được các yếu tố nêu trên của phương pháp phân tích, thiết kế hướng đối tượng. 2.1 Tổng quát về UML UML là ngôn ngữ mô hình hoá, trước hết nó bao gồm một tập các ký pháp thống nhất, thể hiện ngữ nghĩa các định nghĩa trực quan tất cả các thành phần của mô hình ([1], [2]). UML được sử dụng để hiển thị, đặc tả, tổ chức, xây dựng và làm tài liệu các vật phẩm (kết quả) của quá trình phát triển phần mềm hướng đối tượng, đặc biệt là phân tích, thiết kế dưới dạng các báo cáo, biểu đồ, bản mẫu hay các trang web, v.v. UML là ngôn ngữ mô hình hoá độc lập với các công nghệ phát triển phần mềm. 2.1.1 Mục đích của UML Mục đích chính của UML: 1. Mô hình được các hệ thống (không chỉ hệ thống phần mềm) và sử dụng được tất cả các khái niệm hướng đối tượng một cách thống nhất. 2. Cho phép đặc tả, hỗ trợ để đặc tả tường minh (trực quan) mối quan hệ giữa các khái niệm cơ bản trong hệ thống, đồng thời mô tả được mọi trạng thái hoạt động của hệ thống đối tượng. Nghĩa là cho phép mô tả được cả mô hình tĩnh lẫn mô hình động một cách đầy đủ và trực quan. 3. Tận dụng được những khả năng sử dụng lại và kế thừa ở phạm vi diện rộng để xây dựng được những hệ thống phức tạp và nhạy cảm như: các hệ thống động, hệ thống thời gian thực, hệ thống nhúng thời gian thực, v.v. 4. Tạo ra những ngôn ngữ mô hình hoá sử dụng được cho cả người lẫn máy tính. - 35 -
Phân tích, thiết kế hướng đối tượng bằng UM L Đoàn Văn Ban Tóm lại, UML là ngôn ngữ mô hình hoá, ngôn ngữ đặc tả và ngôn ngữ xây dựng mô hình trong quá trình phát triển phần mềm, đặc biệt là trong phân tích và thiết kế hệ thống hướng đối tượng. UML là ngôn ngữ hình thức, thống nhất và chuẩn hoá mô hình hệ thống một cách trực quan. Nghĩa là các thành phần trong mô hình được thể hiện bởi các ký hiệu đồ hoạ, biểu đồ và thể hiện đầy đủ mối quan hệ giữa các chúng một cách thống nhất và có logic chặt chẽ. Tuy nhiên cũng cần lưu ý: UML không phải là ngôn ngữ lập trình, nghĩa là ta không thể dùng UML để viết chương trình. Nó cũng không phải là một công cụ CASE. Một số công cụ CASE như Rational Rose [17] sử dụng mô hình UML để phát sinh mã nguồn tự động sang những ngôn ngữ lập trình được lựa chọn như C++, Java, Visual C++, v.v. UML cũng không phải là một phương pháp hay một quá trình phát triển phần mềm. Các ký hiệu UML được sử dụng trong các dự án phát triển phần mềm nhằm áp dụng những cách tiếp cận khác nhau cho quá trình phát triển phần mềm nhằm tách chu kỳ phát triển hệ thống thành những hoạt động, các tác vụ, các giai đoạn và các bước khác nhau. 2.1.2 Quá trình phát triển phần mềm thống nhất với UML UML được phát triển để đặc tả quá trình phát triển phần mềm, nhằm mô hình hoá hệ thống. Quá trình phát triển phần mềm này gọi là quá trình phát triển phần mềm hợp nhất (USPD) hay quá trình hợp nhất Rational (RUP [17, 21]), gọi tắt là quá trình hợp nhất (UP). RUP là tập các qui tắc hướng dẫn về phương diện kỹ thuật và tổ chức để phát triển phần mềm, nhấn mạnh chủ yếu vào các bước phân tích và thiết kế. RUP được cấu trúc theo hai chiều: 1. Chiều thời gian: chia quá trình thành các pha thực hiện và các bước lặp. 2. Chiều thành phần: các sản phẩm cùng với các hoạt động được xác định đầy đủ. 1. Cấu trúc dự án theo chiều thời gian bao gồm các pha thực hiện: (i) Khởi động (Inception): xác định dự án tổng thể (ii) Soạn thảo dự án tỉ mỉ (Elaboration): + Lập kế hoặch cho những hoạt động cần thiết + Xác định những tài nguyên cần để thực hiện dự án + Xác định các tính chất, đặc trưng của dự án + Xây dựng kiến trúc cho hệ thống. (iii) Xác định những sản phẩm ở mỗi pha thực hiện. (iv) Chuyển giao: cung cấp sản phẩm cho cộng đồng người sử dụng. - 36 -
Phân tích, thiết kế hướng đối tượng bằng UM L Đoàn Văn Ban 2. Cấu trúc dự án theo chiều thành phần bao gồm các hoạt động: Mô hình hoá nghiệp vụ: thiết lập các khả năng của hệ thống cần xây dựng và nhu cầu của NSD. Phân tích các yêu cầu: chi tiết các yêu cầu chức năng và phi chức năng của hệ thống. Phân tích thiết kế hệ thống: mô tả hệ thống thực hiện các yêu cầu và hỗ trợ cài đặt. Cài đặt chương trình: lập trình những kết quả thiết kế nêu trên để hệ thống hoạt động đúng theu yêu cầu. Kiểm thử, kiểm chứng các thành phần và toàn bộ hệ thống. Triển khai hệ thống: khai thác hệ thống và huấn luyện NSD. UP bao gồm con người, dự án, sản phẩm, qui trình và công cụ. Con người là những người tham gia dự án để tạo ra sản phẩm phần mềm theo một quá trình với sự hỗ trợ của công cụ được cung cấp. UP là quá trình phát triển phần mềm được hướng dẫn bởi các ca sử dụng. Nghĩa là các yêu cầu của NSD được mô tả trong các ca sử dụng, là chuỗi các hành động được thực hiện bởi hệ thống nhằm cung cấp các dịch vụ, các thông tin cho khách hàng. Các ca sử dụng bao gồm chuỗi các công việc được xem là nền tảng để tạo ra mô hình thiết kế và cài đặt hệ thống. UP cũng là qui trình tập trung vào kiến trúc, được lặp và phát triển tăng trưởng liên tục. Kiến trúc của hệ thống phải được thiết kế nhằm đáp ứng các yêu cầu của các ca sử dụng chính, trong giới hạn của chuẩn phần cứng mà hệ thống sẽ chạy và của cấu trúc của cả hệ thống lẫn các hệ thống con. Tính lặp của quá trình phát triển phần mềm được thể hiện ở chỗ là một dự án được chia thành các dự án nhỏ và được thực hiện lặp lại trong từng bước thực hiện. Mỗi dự án nhỏ đều thực hiện phân tích, thiết kế, cài đặt và kiểm thử, v.v. Mỗi phần việc đó được phát triển tăng trưởng và cả dự án cũng được thực hiện theo sự tăng trưởng này. UP không chỉ tạo ra một hệ thống phần mềm hoàn chỉnh mà còn tạo ra một số sản phẩm trung gian như các mô hình. Các mô hình chính trong UP là mô hình nghiệp vụ (ca sử dụng), mô hình khái niệm, mô hình thiết kế, mô hình triển khai và mô hình trắc nghiệm. Các mô hình này có sự phụ thuộc theo vết phát triển, nghĩa là có thể lần theo từng mô hình để đến được mô hình trước. 2.1.3 Giới thiệu tổng quát về UML UML được xây dựng dựa chính vào: Cách tiếp cận của Booch (Booch Approach), Kỹ thuật mô hình đối tượng (OMT – Object Modeling Technique) của Rumbaugh, Công nghệ phần mềm hướng đối tượng (OOSE – Object-Oriented Software Engineering) của Jacobson, - 37 -
Phân tích, thiết kế hướng đối tượng bằng UM L Đoàn Văn Ban Đồng thời thống nhất được nhiều ký pháp, khái niệm của các phương pháp khác. Quá trình hình thành UML bắt đầu từ ngôn ngữ Ada (Booch) trước năm 1990 (hình 2-1). Ada / Booch 1990 Booch 91 OOSE OMT Jacobson Rumbaugh Booch 93 OOSE 94 OMT 94 1995 UML 0.9 Booch /Rumbaugh UML 0.9 Amigos 1997 UML 1.0 UML 1.1 11/ 1997 được chấp nhận Hình 2-1 Sự phát triển của UML Để hiểu và sử dụng tốt UML trong phân tích, thiết kế hệ thống, đòi hỏi phải nắm bắt được ba vấn đề chính: 1. Các phần tử cơ bản của UML, 2. Những qui định liên kết giữa các phần tử, các qui tắc cú pháp, 3. Những cơ chế chung áp dụng cho ngôn ngữ mô hình hoá hệ thống. - 38 -
Phân tích, thiết kế hướng đối tượng bằng UM L Đoàn Văn Ban 2.1.4 Các phần tử của UML UML Các sự vật Các mối quan Các biểu Các quan sát hệ đồ Cấu trúc Hành vi Gộp nhóm Chú dẫn Phụ thuộc Ca sử dụng Ca sử dụng Kết hợp Lớp Logic Kết nhập Đối tượng Thành phần Tổng quát hoá Trình tự Sự tương tranh Ca sử dụng Sự tương tác Gói (kế thừa) Cộng tác Triển khai L ớp Máy trạng Mô hình Trạng thái Giao diện thái Hệ thống con Hoạt động Lớp tích cực Khung công việc Thành phần Thành phần Triển khai Cộng tác Nút Hình 2-2 Các thành phần cơ sở của UML Các quan sát Các quan sát (góc nhìn) theo các phương diện khác nhau của hệ thống cần phân tích, thiết kế. Dựa vào các quan sát để thiết lập kiến trúc cho hệ thống cần phát triển. Có năm loại quan sát: quan sát theo ca sử dụng, quan sát logic, quan sát thành phần, quan sát tương tranh và quan sát triển khai. Mỗi quan sát tập trung khảo sát và mô tả một khía cạnh của hệ thống (hình 2-3) và thường được thể hiện trong một số biểu đồ nhất định. Quan sát Quan sát thành phần logic Quan sát ca sử dụng Quan sát Quan sát triển khai tương tranh Hình 2-3 Các quan sát của hệ thống Quan sát các ca sử dụng (hay trường hợp sử dụng): mô tả các chức năng, nhiệm vụ của hệ thống. Quan sát này thể hiện mọi yêu cầu của hệ thống, do vậy nó phải được xác định ngay từ đầu và nó được sử dụng để điều khiển, thúc đẩy và thẩm định hay kiểm tra các công việc của tất cả các giai đoạn của cả quá trình phát triển phần mềm. Nó cũng là cơ sở để trao đổi giữa các thành - 39 -
Phân tích, thiết kế hướng đối tượng bằng UM L Đoàn Văn Ban viên của dự án phần mềm và với khách hàng. Quan sát ca sử dụng được thể hiện trong các biểu đồ ca sử và có thể ở một vài biểu đồ trình tự, cộng tác, v.v. Quan sát logic biểu diễn cách tổ chức logic của các lớp và các quan hệ của chúng với nhau. Nó mô tả cấu trúc tĩnh của các lớp, đối tượng và sự liên hệ của chúng thể hiện mối liên kết động thông qua sự trao đổi các thông điệp. Quan sát được thể hiện trong các biểu đồ lớp, biểu đồ đối tượng, biểu đồ tương tác, biểu đồ biến đổi trạng thái. Quan sát logic tập trung vào cấu trúc của hệ thống. Trong quan sát này ta nhận ra các bộ phận cơ bản cấu thành hệ thống thể hiện mọi quá trình trao đổi, xử lý thông tin cơ bản trong hệ thống. Quan sát thành phần (quan sát cài đặt) xác định các mô đun vật lý hay tệp mã chương trình và sự liên hệ giữa chúng để tổ chức thành hệ thống phần mềm. Trong quan sát này ta cần bổ sung: chiến lược cấp phát tài nguyên cho từng thành phần, và thông tin quản lý như báo cáo tiến độ thực hiện công việc, v.v. Quan sát thành phần được thể hiện trong các biểu đồ thành phần và các gói. Quan sát tương tranh (quan sát tiến trình) biểu diễn sự phân chia các luồng thực hiện công việc, các lớp đối tượng cho các tiến trình và sự đồng bộ giữa các luồng trong hệ thống. Quan sát này tập trung vào các nhiệm vụ tương tranh, tương tác với nhau trong hệ thống đa nhiệm. Quan sát triển khai mô tả sự phân bổ tài nguyên và nhiệm vụ trong hệ thống. Nó liên quan đến các tầng kiến trúc của phần mềm, thường là kiến trúc ba tầng: tầng giao diện (tầng trình diễn hay tầng sử dụng), tầng logic tác nghiệp và tầng lưu trữ CSDL được tổ chức trên một hay nhiều máy tính khác nhau. Quan sát triển khai bao gồm các luồng công việc, bộ xử lý và các thiết bị. Biểu đồ triển khai mô tả các tiến trình và chỉ ra những tiến trình nào trên máy nào. Các sự vật (các phần tử của mô hình) UML có bốn phần tử mô hình, đó là cấu trúc, hành vi, nhóm và chú thích. Phần tử cấu trúc: là các danh từ trong mô hình UML, biểu diễn cho các thành phần khái niệm hay vật lý của hệ thống. UML có bảy phần tử cấu trúc được mô tả như sau: + Lớp. Lớp là tập các đối tượng cùng chia sẻ với nhau về các thuộc tính, thao tác, quan hệ và ngữ nghĩa. + Giao diện. Giao diện là tập các thao tác làm dịch vụ cho lớp hay thành phần. Giao diện mô tả hành vi quan sát được từ bên ngoài thành phần. Giao diện chỉ khai báo các phương thức xử lý nhưng không định nghĩa nội dung thực hiện. Nó thường không đứng một mình mà thường được gắn với lớp hay một thành phần. + Phần tử cộng tác. Phần tử cộng tác mô tả ngữ cảnh của sự tương tác trong hệ thống. Nó thể hiện một giải pháp thi hành trong hệ thống, bao gồm các lớp, quan hệ và sự tương tác giưa chúng để thực hiện một ca sử dụng như mong đợi. - 40 -
Phân tích, thiết kế hướng đối tượng bằng UM L Đoàn Văn Ban + Ca sử dụng. Ca sử dụng mô tả một tập các hành động mà hệ thống sẽ thực hiện để phục vụ cho các tác nhân ngoài. Tác nhân ngoài là những gì bên ngoài có tương tác, trao đổi với hệ thống. + Lớp tích cực. Lớp tích cực được xem như là lớp có đối tượng làm chủ một hay nhiểu tiến trình, luồng hành động. + Thành phần. Thành phần biểu diễn vật lý mã nguồn, các tệp nhị phân trong quá trình phát triển hệ thống. + Nút. Nút thể hiện thành phần vật lý tồn tại khi chương trình chạy và biểu diễn cho các tài nguyên được sử dụng trong hệ thống. Phần tử mô tả hành vi: là các động từ của mô hình, biểu diễn hành vi trong sự tương tác của các thành phần và sự biến đổi trạng thái của hệ thống. Có hai loại chính là sự tương tác và máy biến đổi trạng thái. + Sự tương tác. Sự tương tác là hành vi bao gồm một tập các thông điệp trao đổi giữa các đối tượng trong một ngữ cảnh cụ thể để thực hiện một ca sử dụng. + Máy biến đổi trạng thái. Máy biến đổi trạng thái (ôtômát hữu hạn trạng thái) chỉ ra trật tự thay đổi trạng trái khi các đối tượng hay sự tương tác sẽ phải đi qua để đáp ứng các sự kiện xảy ra. Phần tử nhóm: là bộ phận tổ chức của mô hình UML. Phần tử nhóm có gói, mô hình và khung công việc. + Gói (package). Gói là phần tử đa năng được sử dụng để tổ chức các lớp, hay một số nhóm khác vào trong một nhóm. Không giống với thành phần (component), phần tử gói hoàn toàn là khái niệm, có nghĩa là chúng chỉ tồn tại trong mô hình vào thời điểm phát triển hệ thống chứ không tồn tại vào thời điểm chạy chương trình. Gói giúp ta quan sát hệ thống ở mức tổng quát. + Mô hình. Mô hình là những mô tả về các đặc tính tĩnh và/hoặc động của các chủ thể trong hệ thống. + Khung công việc. Khung công việc là một tập các lớp trừu tượng hay cụ thể được sử dụng như là các khuôn mẫu để giải quyết một họ các vấn đề tương tự. Chú thích: là bộ phận chú giải của mô hình, giải thích về các phần tử, khái niệm và cách sử dụng chúng trong mô hình. Các mối quan hệ UML cho phép biểu diễn cả bốn mối quan hệ giữa các đối tượng trong các hệ thống. Đó là các quan hệ: phụ thuộc, kết hợp, tổng quát hoá và hiện thực hoá. + Quan hệ phụ thuộc. Đây là quan hệ ngữ nghĩa giữa hai phần tử, trong đó sựu thay đổi của một tử sẽ tác động đến ngữ nghĩa của phần tử phụ thuộc. + Quan hệ kết hợp. Kết hợp là quan hệ cấu trúc xác định mối liên kết giữa các lớp đối tượng. Khi có một đối tượng của lớp này gửi/nhận thông điệp đến/từ chỗ đối tượng của lớp kia thì hai lớp đó có quan hệ kết hợp. Một dạng - 41 -
Phân tích, thiết kế hướng đối tượng bằng UM L Đoàn Văn Ban đặc biệt của quan hệ kết hợp là quan hệ kết nhập, biểu diễn mối quan hệ giữa toàn thể và bộ phận. + Quan hệ tổng quát hoá. Đây là quan hệ mô tả sự khái quát hoá mà trong đó một số đối tượng cụ thể (của lớp con) sẽ được kế thừa các thuộc tính, các phương thức của các đối tượng tổng quát (lớp cơ sở). + Hiện thực hoá. Hiện thực hoá là quan hệ ngữ nghĩa giữa giao diện và lớp (hay thành phần) để thực hiện cài đặt các dịch vụ đã được khai báo trong các giao diện. Các biểu đồ Biểu đồ là đồ thị biểu diễn đồ họa về tập các phần tử trong mô hình và mối quan hệ của chúng. Biểu đồ chứa đựng các nội dung của các quan sát dưới các góc độ khác nhau, một thành phần của hệ thống có thể xuất hiện trong một hay nhiều biểu đồ. UML cung cấp những biểu đồ trực quan để biểu diễn các khía cạnh khác nhau của hệ thống, bao gồm: Biểu đồ ca sử dụng mô tả sự tương tác giữa các tác nhân ngoài và hệ thống thông qua các ca sử dụng. Các ca sử dụng là những nhiệm vụ chính, các dịch vụ, những trường hợp sử dụng cụ thể mà hệ thống cung cấp cho người sử dụng và ngược lại. Biểu đồ lớp mô tả cấu trúc tĩnh, mô tả mô hình khái niệm bao gồm các lớp đối tượng và các mối quan hệ của chúng trong hệ thống hướng đối tượng. Biểu đồ trình tự thể hiện sự tương tác của các đối tượng với nhau, chủ yếu là trình tự gửi và nhận thông điệp để thực thi các yêu cầu, các công việc theo thời gian. Biểu đồ cộng tác tương tự như biểu đồ trình tự nhưng nhấn mạnh vào sự tương tác của các đối tượng trên cơ sở cộng tác với nhau bằng cách trao đổi các thông điệp để thực hiện các yêu cầu theo ngữ cảnh công việc. Biểu đồ trạng thái thể hiện chu kỳ hoạt động của các đối tượng, của các hệ thống con và của cả hệ thống. Nó là một loại ôtômát hữu hạn trạng thái, mô tả các trạng thái, các hành động mà đối tượng có thể có và các sự kiện gắn với các trạng thái theo thời gian. Biểu đồ hành động chỉ ra dòng hoạt động của hệ thống, bao gồm các trạng thái hoạt động, trong đó từ một trạng thái hoạt động sẽ chuyển sang trạng thái khác sau khi một hoạt động tương ứng được thực hiện. Nó chỉ ra trình tự các bước, tiến trình thực hiện cũng như các điểm quyết định và sự rẽ nhánh theo luồng sự kiện. Biểu đồ thành phần chỉ ra cấu trúc vật lý của các thành phần trong hệ thống, bao gồm: các thành phần mã nguồn, mã nhị phân, thư viện và các thành phần thực thi. - 42 -
Phân tích, thiết kế hướng đối tượng bằng UM L Đoàn Văn Ban Biểu đồ triển khai chỉ ra cách bố trí vật lý các thành phần theo kiến trúc được thiết kế của hệ thống. Các khái niệm cơ bản của biểu đồ và cách xây dựng các biểu đồ trên để phân tích, thiết kế hệ thống sẽ được giới thệu chi tiết ở các chương sau. 2.2 Các khái niệm cơ bản của phương pháp hướng đối tượng trong UML Để phát triển được hệ thống theo mô hình, phương pháp đã lựa chọn thì vấn đề quan trọng nhất là phải hiểu rõ những khái niệm cơ bản của phương pháp đó. Ở đây chúng ta cần thực hiện phân tích, thiết kế hệ thống theo cách tiếp cận hướng đối tượng, do vậy trước hết phải nắm bắt được những khái niệm cơ sở như: đối tượng, lớp, và các mối quan hệ giữa các lớp đối tượng. Những khái niệm này cũng là các phần tử cơ bản của ngôn ngữ mô hình hóa thống nhất UML. Mô hình hướng đối tượng được sử dụng để phát triển phần mềm dựa trên mô hình dữ liệu trừu tượng và khái niệm lớp để chỉ ra những đặc tính chung các cấu trúc dữ liệu được sử dụng để mô hình hoá hệ thống. Hệ thống các khái niệm cơ bản của phương pháp hướng đối tượng được mô tả như trong hình 2-4. 2.2.1 Các đối tượng Đối tượng là khái niệm cơ sở quan trọng nhất của cách tiếp cận hướng đối tượng. Đối tượng là một khái niệm, một sự trừu tượng hoá hay một sự vật có nghĩa trong bài toán đang khảo sát. Đó chính là các mục mà ta đang nghiên cứu, đang thảo luận về chúng. Đối tượng là thực thể của hệ thống, của CSDL và được xác định thông qua định danh của chúng. Thông thường các đối tượng được mô tả bởi các danh từ riêng (tên gọi) hoặc được tham chiếu tới trong các mô tả của bài toán hay trong các thảo luận với người sử dụng. Có những đối tượng là những thực thể có trong thế giới thực như người, sự vật cụ thể, hoặc là những khái niệm như một công thức, hay khái niệm trừu tượng, v.v. Có một số đối tượng được bổ sung vào hệ thống với lý do phục vụ cho việc cài đặt và có thể không có trong thực tế. Đối tượng là những thực thể được xác định trong thời gian hệ thống hoạt động. Trong giai đoạn phân tích, ta phải đảm bảo rằng các đối tượng đều được xác định bằng các định danh. Đến khâu thiết kế, ta phải lựa chọn cách thể hiện những định danh đó theo cách ghi địa chỉ bộ nhớ, gán các số hiệu, hay dùng tổ hợp một số gái trị của một số thuộc tính để biểu diễn. Theo quan điểm của người lập trình, đối tượng được xem như là một vùng nhớ được phân chia trong máy tính để lưu trữ dữ liệu (thuộc tính) và tập các hàm thao tác trên dữ liệu được gắn với nó. Bởi vì các vùng nhớ được phân hoạch là độc lập với nhau nên các đối tượng có thể tham gia vào nhiều chương trình khác nhau mà không ảnh hưởng lẫn nhau. - 43 -
Phân tích, thiết kế hướng đối tượng bằng UM L Đoàn Văn Ban Kế thừa Lớp Hàm Bao gói Quan hệ Cá thể Đối tượng Thông điệp Đa xạ Hình 2-4 Những khái niệm cơ bản của phương pháp hướng đối tượng 2.2.2 Lớp đối tượng Đối tượng là thể hiện, là một đại biểu của một lớp. Lớp là một mô tả về một nhóm các đối tượng có những tính chất (thuộc tính) giống nhau, có chung các hành vi ứng xử (thao tác gần như nhau), có cùng mối liên quan với các đối tượng của các lớp khác và có chung ngữ nghĩa trong hệ thống. Lớp chính là cơ chế được sử dụng để phân loại các đối tượng của một hệ thống. Lớp thường xuất hiện dưới dạng những danh từ chung trong các tài liệu mô tả bài toán hay trong các thảo luận với người sử dụng. Cũng như các đối tượng, lớp có thể là những nhóm thực thể có trong thế giới thực, cũng có những lớp là khái niệm trừu tượng và có những lớp được đưa vào trong thiết kế để phục vụ cho cài đặt hệ thống, v.v. Lớp và mối quan hệ của chúng có thể mô tả trong các biểu đồ lớp biểu đồ đối tượng và một số biểu đồ khác của UML. Trong biểu đồ lớp, lớp được mô tả bằng một hình hộp chữ nhật, trong đó có tên của lớp, có thể có các thuộc tính và các hàm (phương thức) như hình 2-5. a/ Tên của lớp b/ Tên và thuộc tính c/ Tên, thuộc tính và phương thức Hình 2-5 Các ký hiệu mô tả lớp trong UML Chúng ta nên đặt tên theo một qui tắc thống nhất như sau: + Tên của lớp thì chữ cái đầu của tất cả các từ đều viết hoa, ví dụ: SinhVien, HocSinh, KhachHang, v.v. + Tên của đối tượng, tên của thuộc tính thì viết hoa chữ cái đầu của các từ trừ từ đầu tiên, ví dụ: hoTen, danhSachSV, v.v. - 44 -
Phân tích, thiết kế hướng đối tượng bằng UM L Đoàn Văn Ban + Tên của hàm (phương thức) viết giống như tên của đối tượng nhưng có thêm cặp ngoặc đơn ‘(‘ và ‘)’, ví dụ: hienThi(), nhapDiem(), v.v. Trong biểu đồ ở giai đoạn phân tích, một lớp có thể chỉ cần có tên lớp, tên và thuộc tính, hoặc có cả tên gọi, thuộc tính và các phương thức như hình 2-5. 2.2.3 Các giá trị và các thuộc tính của đối tượng Giá trị (value) là một phần của dữ liệu. Các giá trị thường là các số hoặc là các ký tự. Thuộc tính của đối tượng là thuộc tính của lớp được mô tả bởi giá trị của mỗi đối tượng trong lớp đó. Ví dụ sv1: SinhVien hoTen = Van Ba tuoi = 20 Hình 2-6 Ký hiệu đối tượng trong UML “Van Ba” và 20 là hai giá trị tương ứng với hai thuộc tính hoTen, tuoi của đối tượng sv1 trong lớp SinhVien. Không nên nhầm lẫn giá trị với đối tượng. Các đối tượng có định danh chứ không phải là các giá trị. Có thể có ba sinh viên cùng tên “Van Ba”, nhưng trong hệ thống các sinh viên này phải được quản lý theo định danh để xác định duy nhất từng đối tượng. Giá trị có thể là các giá trị của các kiểu dữ liệu nguyên thuỷ như các kiểu số hoặc các kiểu xâu ký tự, hoặc là tập hợp của các giá trị nguyên thuỷ. Các dữ liệu thành phần của một lớp có thể được bao gói thông qua các thuộc tính quản lý sự truy nhập để phục vụ việc che giấu thông tin của phương pháp hướng đối tượng. Trong UML ta có thể sử dụng các ký hiệu để đặc tả các thuộc tính đó. Ký hiệu: ‘+’ đứng trước tên thuộc tính, hàm xác định tính công khai (public), mọi đối tượng trong hệ thống đều nhìn thấy được. Nghĩa là mọi đối tượng đều có thể truy nhập được vào dữ liệu công khai. Trong Rose [17] ký hiệu là ổ khoá không bị khoá. ‘#’ đứng trước tên thuộc tính, hàm xác định tính được bảo vệ (protected), chỉ những đối tượng có quan hệ kế thừa với nhau nhìn thấy được. Trong Rose ký hiệu là ổ khoá bị khoá, nhưng có chìa để bên cạnh. ‘-‘ đứng trước tên thuộc tính, hàm xác định tính sở hữu riêng (private), chỉ các đối tượng trong cùng lớp mới nhìn thấy được. Trong Rose ký hiệu là ổ khoá bị khoá và không có chìa để bên cạnh. Trong trường hợp không sử dụng một trong ba ký hiệu trên thì đó là trường hợp mặc định. Thuộc tính quản lý truy cập mặc định của những hệ thống khác nhau có thể khác nhau, ví dụ trong C++, các thuộc tính mặc định trong lớp được qui định là private, còn trong Java lại qui định khác, đó là những thuộc tính rộng hơn private. - 45 -
Phân tích, thiết kế hướng đối tượng bằng UM L Đoàn Văn Ban Những thuộc tính trên thiết lập quyền truy cập cho mọi đối tượng trong các lớp, các gói, các hệ thống con của hệ thống phần mềm [2, 3]. 2.2.4 Các thao tác và phương thức Thao tác là một hàm hay thủ tục có thể áp dụng (gọi hàm) cho hoặc bởi các đối tượng trong một lớp. Khi nói tới một thao tác là ngầm định nói tới một đối tượng đích để thực hiện thao tác đó. Ví dụ, thao tác (hàm) hienThi() của lớp MonHoc khi gọi để hiển thị các về sinh viên học một môn học cụ thể như “Lập trình hướng đối tượng” chẳng hạn. Một phương thức là một cách thức cài đặt của một thao tác trong một lớp [14]. Một số thao tác có thể là đa xạ, được nạp chồng, nghĩa là nó có thể áp dụng cho nhiều lớp khác nhau với những nội dung thực hiện có thể khác nhau, nhưng cùng tên gọi. Ví dụ lớp ThietBi có hàm tinhGia(). Hàm này có thể nạp chồng, bởi vì có nhiều phương thức (công thức) tính giá bán khác nhau tuỳ thuộc vào từng loại thiết bị. Tất cả các phương thức này đều thực hiện một nhiệm vụ tinhGia(), nhưng được cài đặt với nội dung (các đoạn chương trình) khác nhau. Hệ thống hướng đối tượng tự động chọn phương thức tương ứng với ngữ cảnh của đối tượng đích để thực hiện. Tương tự như các dữ liệu thành phần, các phương thức cũng được quản lý truy cập và được ký hiệu như trên. Lưu ý: Một số tác giả ([10], [11], [15]) không phân biệt thao tác, hàm với phương thức mà có thể đồng nhất chúng với nhau trong quá trình phân tích, thiết kế và lập trình. Trong các phần sau chúng ta gọi chung là hàm hoặc hàm thành phần. 2.3 Các mối quan hệ giữa các lớp Hệ thống hướng đối tượng là tập các đối tượng tương tác với nhau để thực hiện công việc theo yêu cầu. Quan hệ là kết nối ngữ nghĩa giữa các lớp đối tượng, trong đó thể hiện mối liên quan về các thuộc tính, các thao tác của chúng với nhau trong hệ thống. Các quan hệ này được thể hiện chính trong biểu đồ lớp. Giữa các lớp có năm quan hệ cơ bản: Quan hệ kết hợp, Quan hệ kết nhập, Quan hệ tổng quát hóa, kế thừa, Quan hệ phụ thuộc, Hiện thực hoá. Để hiểu rõ hơn về các mối quan hệ trong hệ thống, trước tiên chúng ta cần phân biệt các mối quan hệ giữa các lớp và giữa các đối tượng với nhau. 2.3.1 Sự liên kết và kết hợp giữa các đối tượng Một liên kết là một sự kết nối vật lý hoặc logic giữa các đối tượng với nhau. Phần lớn các liên kết là sự kết nối giữa hai đối tượng với nhau. Tuy nhiên cũng có những liên kết giữa ba hoặc nhiều hơn ba đối tượng. Nhưng các ngôn ngữ lập trình hiện nay hầu như chỉ cài đặt những liên kết (phép toán) nhiều nhất là ba ngôi. - 46 -