Giáo trình Nhập môn công nghệ phần mềm (Trình độ Cao đẳng)

các mục đích về đào tạo và tham khảo. Mọi mục đích khác mang tính lệch lạc hoặc sử dụng với mục đích kinh doanh thiếu lành mạnh sẽ bị nghiêm cấm. MÃ TÀI LIỆU: MHCNTT 18 2LỜI GIỚI THIỆU Mục tiêu của môn Nhập môn Công nghệ phần mềm là cung cấp cho sinh viên những kiến thức cơ bản về tất cả mọi hoạt động liên quan đến phát triển phần mềm và kiến thức cơ bản về UML trong phát triển phần mềm. Qua môn học này sinh viên có kỹ năng sử dụng công cụ phần mềm để thực hiện các pha trong quá trình phát triển phần mềm và qua đó nâng cao năng lực làm việc nhóm và kỹ năng mềm. Sinh viên tham dự lớp và thực hành đầy đủ đặc biệt tích cực tham gia thảo luận trình bày trên lớp là yêu cầu quan trọng. Các nội dung chính được trình bày trong tài liệu này gồm các chương: - Giới thiệu chung về phần mềm và công nghệ phần mềm - Một số mô hình vòng đời phát triển phần mềm - Xác định và đặc tả yêu cầu - Thiết kế phần mềm - Kiểm thử phần mềm Mặc dầu có rất nhiều cố gắng, nhưng không tránh khỏi những khiếm khuyết, rất mong nhận được sự đóng góp ý kiến của độc giả để giáo trình được hoàn thiện hơn. Xin chân thành cảm ơn! Hà Nội, ngày 23 tháng 04 năm 2021 Tham gia biên soạn 1. Chủ biên Phùng Sỹ Tiến Trưởng khoa 2. Tập thể Giảng viên Khoa CNTT Mọi thông tin đóng góp chia sẻ xin gửi về hòm thư tienphungktcn@gmail.com, hoặc liên hệ số điện thoại 0913393834-0983393834 3MỤC LỤC LỜI GIỚI THIỆU ................................................................................................... 2 CHƯƠNG 1: GIỚI THIỆU CHUNG ...................................................................... 7 VỀ PHẦN MỀM VÀ CÔNG NGHỆ PHẦN MỀM ................................................ 7 1. Khái niệm về phần mềm ............................................................................. 7 1.1. Định nghĩa chung về phần mềm .......................................................... 7 1 .2 . Các đặc tính của phần mềm ....................................................................... 8 1.3. Thế nào là một phần mềm tốt ? ......................................................... 10 1.4. Ứng dụng phần mềm ........................................................................ 11 2. Công nghệ phần mềm ................................................................................ 12 CHƯƠNG 2: MỘT SỐ MÔ HÌNH VÒNG ĐỜI PHÁT TRIỂN PHẦN MỀM ...... 14 1. Các khái niệm cơ bản ................................................................................... 14 1.1. Vòng đời phần mềm ......................................................................... 14 1.2. Quy trình phát triển phần mềm .............................................................. 15 2. Một số mô hình vòng đời phát triển phần mềm............................................. 16 2.2. Mô hình thuần thục khả năng ................................................................ 16 2.3. Mô hình chế thử .................................................................................... 17 2.4. Mô hình phát triển ứng dụng nhanh (RAD) ........................................... 18 2.5. Mô hình xoắn ốc ................................................................................... 20 2.6. Mô hình theo thành phần ....................................................................... 21 2.9. Mô hình chữ V ..................................................................................... 23 CHƯƠNG 3: XÁC ĐỊNH VÀ ĐẶC TẢ YÊU CẦU ............................................ 24 1. Tổng quan về yêu cầu phần mềm ................................................................. 24 1.1. Khái niệm yêu cầu phần mềm ............................................................... 24 1.2. Phân loại các yêu cầu phần mềm ........................................................... 24 2. Xác định yêu cầu phần mềm ......................................................................... 24 2.1. Nội dung xác định yêu cầu phần mềm ................................................... 24 2.2 Phát hiện các yêu cầu phần mềm ............................................................ 25 2.3. Phân tích các yêu cầu phần mềm và thương lượng với khách hàng........ 26 3. Đặc tả yêu cầu .............................................................................................. 26 4. Thẩm định yêu cầu ....................................................................................... 27 CHƯƠNG 4: THIẾT KẾ PHẦN MỀM ................................................................ 35 1. Tổng quan về thiết kế phần mềm .................................................................. 35 1.1 Khái niệm và vai trò của thiết kế ............................................................ 35 1.2. Tiến trình thiết kế .................................................................................. 37 4.1. Một số khái niệm UML ......................................................................... 40 4.2. Tiến trình thiết kế hướng đối tượng ....................................................... 43 CHƯƠNG 5: KIỂM THỬ PHẦN MỀM .............................................................. 49 1. Một số khái niệm cơ bản .............................................................................. 49 1.1 Đặc tả và lỗi phần mềm. ......................................................................... 50 1.2. Kiểm thử và tiến trình kiểm thử............................................................. 52 1.3 Các mức kiểm thử .................................................................................. 53 1.4 Một số thuật ngữ .................................................................................... 56 2. Các cấp độ kiểm thử ..................................................................................... 57 2.1. Kiểm thử đơn vị.................................................................................... 57 2.2. Kiểm thử tích hợp ................................................................................. 57 42.3. Kiểm thử hệ thống ................................................................................ 58 2.4. Kiểm thử chấp nhận.............................................................................. 58 3. Các kỹ thuật kiểm thử. ................................................................................. 58 3.1. Kiểm thử hộp đen - Black-box Testing .................................................. 58 3.2 Kiểm thử hộp trắng - White-box Testing ................................................ 60 TÀI LIỆU THAM KHẢO .................................................................................... 62 5GIÁO TRÌNH MÔN HỌC Tên môn học: Nhập môn công nghệ phần mềm Mã môn học: MHCNTT 18 Vị trí, tính chất, ý nghĩa và vai trò môn học: - Vị trí: Môn học Nhập môn Công nghệ phần mềm dành cho sinh viên trình độ Cao đẳng. Môn học thuộc khối kiến thức chuyên ngành.. - Tính chất: Môn học giúp sinh viên hiểu rõ được các khái niệm và phương pháp kỹ thuật liên quan đến tiến trình phát triển phần mềm, bắt đầu từ công việc đặc tả, xác định yêu cầu, phân tích thiết kế phần mềm. Giới thiệu các công cụ hỗ trợ thiết kế, lập trình để phát triển phần mềm và kiểm thử phần mềm để sinh viên có kiến thức tổng quan nhất về quy trình phát triển một phần mềm và ứng dụng được kiến thức đó vào công việc phát triển phần mềm sau này. - Ý nghĩa và vai trò của môn học: Đây là môn học cơ sở ngành, cung cấp cho sinh viên các kiến thức cơ bản về phần mềm và lập trình phần mềm. Mục tiêu của môn học: - Về kiến thức: + Trình bày được một số kiến thức cơ bản về khái niệm về phần mềm và công nghệ phần mềm, các phương pháp kỹ thuật liên quan đến tiến trình phát triển phần mềm. + Hiểu rõ các công cụ hỗ trợ công việc đặc tả và xác định yêu cầu, thiết kế và lập kế hoạch để phát triển phần mềm.; - Về kỹ năng + Lựa chọn được phương pháp kỹ thuật phù hợp cho một dự án phần mềm. + Vận dụng được các công cụ hỗ trợ, kỹ thuật lập trình để phát triển phần mềm + Xác định và ý thức được mục tiêu, ý nghĩa và vị trí của học phần Nhập môn Công nghệ phần mềm trong chương trình đào tạo - Về năng lực tự chủ và trách nhiệm: + Đi học đầy đủ, tích cực tham gia thao luận, chăm chỉ đọc tài liệu tham khảo để có được những kiến thức quan trọng của công nghệ phần mềm đối với khoa học máy tính. + Hăng say, nhiệt tình, có khả năng tự nghiên cứu Nội dung của môn học: Số TT Tên chương, mục Thời gian Tổng số Lý thuyết Thực hành Kiểm tra* (LT hoặc TH) I Giới thiệu chung về phần mềm và công nghệ phần mềm 6 3 3 Khái niệm về phần mềm Công nghệ phần mềm II Một số mô hình vòng đời phát triển phần mềm 6 3 3 Các khái niệm cơ bản Một số mô hình vòng đời phát 6triển phần mềm III Xác định và đặc tả yêu cầu 11 7 4 Tồng quan về yêu cầu phần mềm Xác định yêu cầu phần mềm Đặc tả yêu cầu Thẩm định yêu cầu IV Thiết kế phần mềm 15 11 3 1 Tổng quan về thiết kế phần mềm Thiết kế kiến trúc Thiết kế hệ thống hướng chức năng Thiết kế hệ thống hướng đối tượng Thiết kế giao diện V Kiểm thử phần mềm Một số khái niệm cơ bản Các cấp độ kiểm thử Các kỹ thuật kiểm thử 6 3 3 Thi kết thúc môn học 1 1 Cộng 45 27 16 2 7CHƯƠNG 1: GIỚI THIỆU CHUNG VỀ PHẦN MỀM VÀ CÔNG NGHỆ PHẦN MỀM Mã chương: MHCNTT 18.1 Mục tiêu: - Nêu được các định nghĩa, khái niệm về phần mềm và công nghệ phần mềm. - Nêu được lịch sử hình thành và phát triển công nghệ phần mềm. - Trình bày được tầm quan trọng của công nghệ phần mềm 1. Khái niệm về phần mềm Mục tiêu: Nắm được định nghĩa phần mềm; Nắm được các đặc tính của phần mềm. 1.1. Định nghĩa chung về phần mềm Trong ba thập kỷ đầu tiên của thời đại tính toán, thách thức chủ yếu là phải phát triển ứng dụng phần cứng máy tính để làm giảm bớt giá thành xử lý và lưu trữ dữ liệu. Trong suốt thập kỷ 80, tiến bộ trong vi điện tử đã làm phát sinh năng lực tính toán mạnh hơn với giá thành thấp đáng kể. Ngày nay vấn đề đã khác đi. Thách thức chủ yếu là phải cải tiến chất lượng và giảm giá thành của các giải pháp dựa trên máy tính - giải pháp được cài đặt bằng phần mềm. Vậy phần mềm là gì? Định nghĩa 1: Phần mềm là tập họp: 1. Các lệnh (chương trình máy tính) khi được thực hiện sẽ cung cấp những chức năng và kết quả mong muốn. 2. Cấu trúc dữ liệu làm cho chương trình thao tác thông tin thích hợp. 3. Các tư liệu mô tả thao tác và cách sử dụng chương trình. Định nghĩa 2: Trong một hệ thống máy tính, nếu trừ bỏ đi các thiết bị và các loại phụ kiện thì phần còn lại chính là các phần mềm. Nghĩa hẹp- phần mềm là dịch vụ chương trình để tăng khả năng xử lý của phần cứng máy tính. Nghĩa rộng- phần mềm là tập tất cả các kỹ thuật ứng dụng để thực hiện những dịch vụ chức năng cho các mục đích nào đó bằng phần cứng. Tóm lại : Phần mềm được biểu diễn như hình 1.1. Hình 1.1. Phần mềm là gi? 8Trong đó: ■ Nhóm các kỹ thuật, phương pháp luận bao gồm: -Các khái niệm và trình tự cụ thể hoá của một hệ thống; -Các phương pháp tiếp cận và giải quyết vấn đề; -Các trình tự thiết kế và phát triển được chuẩn hoá (quy trình); -Các phương pháp đặc tả, yêu cầu, thiết kế hệ thống, thiết kế chương trình, kiểm thử, toàn bộ quy trình quản lý phát triển phần mềm. ■ Nhóm các chương trình là phần giao diện với phần cứng, con người từ các nhóm lệnh chỉ thị cho máy tính biết trình tự thao tác xử lý dữ liệu. ■ Nhóm các tư liệu: -Những tài liệu hữu ích, có giá trị cao và rất cần thiết để phát triển, vận hành và bảo trì phần mềm. -Để tạo ra phần mềm với độ tin cậy cao cần phải tạo ra các tư liệu chất lượng cao: đặc tả yêu cầu, mô tả thiết kế từng loại, điều kiện kiểm thử, thủ tục vận hành, hướng dẫn thao tác. ■ Những yếu tố khác: -Sản xuất phần mềm phụ thuộc rất nhiều vào con người (kỹ sư phần mềm). Khả năng hệ thống hoá trừu tượng, khả năng lập trình, kỹ năng công nghệ, kinh nghiệm làm việc, tầm bao quát... khác nhau ở mỗi người. -Phần mềm phụ thuộc nhiều vào ý tưởng và kỹ năng của con người/nhóm tác giả. 1 .2 . Các đặc tính của phần mềm Để hiểu được khái niệm phần mềm, cần xem xét các đặc trưng của phần mềm làm cho nó khác biệt với những thứ khác mà con người đã xây dựng, Khi phần cứng được xây dựng, tiến trình sáng tạo của con người (phân tích, thiết kế, xây dựng, kiểm thử) cuối cùng được dịch thành dạng vật lý. Phần mềm là hệ thống logic, không phải là hệ thống vật lý. Do đó, phần mềm có các đặc trưng khác với các đặc trưng của phần cứng: Phần mềm được phát triển hay được kỹ nghệ hoá, nó không được chế tạo theo nghĩa cổ điển. Mặc dù có một số điểm tương đồng giữa phát triển phần mềm và chế tạo phần cứng nhưng hai hoạt động này về cơ bản là khác nhau. Trong cả hai hoạt động này, chất lượng cao sẽ đạt được nếu thiết kế tốt, nhưng giai đoạn chế tạo phần cứng có thể đưa ra các vấn đề chất lượng, điều mà không tồn tại hay dễ sửa đổi ở phần mềm. Cả hai hoạt động này đều phụ thuộc vào con người nhưng mối quan hệ giữa người được áp dụng và công việc là hoàn toàn khác nhau. Phần mềm không hỏng đi Phần mềm không bị tác động bởi môi trường - yếu tố vốn gây cho phần cứng bị mòn cũ đi. Do đó về lý thuyết, đường cong tỷ lệ hỏng hóc phần mềm có dạng như hình 1.2. Những khiếm khuyết chưa được phát hiện sẽ làm cho chương trình có tỷ lệ hỏng hóc cao ngay từ ban đầu khi mới sử dụng. Tuy nhiên, những khiếm khuyết này được sửa đổi và đường cong trở nên phẳng như hình vẽ. Phần mềm không mòn cũ đi nhưng nó bị ‘‘suy thoái”. Điều này dường như mâu thuẫn nhưng có thể được giải thích rõ ràng nhất trong hình 1.3. 9Hình 1.2. Đường cong hỏng hóc phần mềm (lý tưởng) Hình 1.3. Đường cong hỏng hóc thực tế của phần mềm Trong quá trình sử dụng, phần mềm sẽ có nhiều thay đổi. Khi thay đổi được thực hiện, có thể một số khiếm khuyết mới sẽ xuất hiện, làm cho đường cong tỷ lệ hỏng hóc trở thành có đầu nhọn như hình vẽ. Trước khi đường cong trở về với tỷ lệ hỏng hóc ổn định ban đầu thì một thay đổi khác lại được thực hiện và làm cho đường cong phát sinh đỉnh nhọn một lần nữa. Dần dần, mức tỷ lệ hỏng hóc tối thiểu bắt đầu nâng lên - phần mềm bị thoái hoá do những thay đổi. Một khía cạnh khác của sự mòn sẽ minh hoạ cho sự khác biệt giữa phần cứng và phần mềm : Khi một yếu tố phần cứng bị mòn cũ đi, nó liền được thay thế. Nhưng không có phần thay thế cho phần mềm. Mọi hỏng hóc phần mềm đều chỉ ra lỗi thiết kế hay đường quá trình chuyển thiết kế thành mã máy thực hiện được. Do đó, việc bảo trì phần mềm có độ phức tạp phụ thêm đáng kể so với bảo trì phần cứng. Phần lớn phần mềm đều được xây dựng theo các đơn đặt hàng, ít khi được lắp ráp từ các thành phần có sẵn. Nói chung không có danh mục các thành phần phần mềm. Có thể đặt hàng phần mềm nhưng chỉ như một đơn vị hoàn chỉnh, không phải là những thành phần có thể 10 lắp ráp lại thành chương trình mới. Mặc dù có nhiều bài viết đề cập tới vấn đề tái sử dụng phần mềm, nhưng chúng ta cũng mới chỉ thu được rất ít hiệu quả từ việc tái sử dụng này. 1.3. Thế nào là một phần mềm tốt ? ■ Các chỉ tiêu cơ bản bao gồm: - Phản ánh đúng yêu cầu người dùng. - Chứa ít lỗi tiềm tàng. - Giá thành không vượt quá ước lượng ban đầu. - Dễ vận hành sử dụng. - Tính an toàn, độ tin cậy cao. ■ Hiệu suất xử lý cao: - Hiệu suất thời gian tốt: Độ phức tạp tính toán thấp, thời gian quay vòng ngắn, thời gian hồi đáp nhanh. - Sử dụng các tài nguyên như CPU, RAM, HDD, Internet một cách hữu hiệu. ■ Tính dễ hiểu: - Kiến trúc và cấu trúc dễ hiểu. - Dễ kiểm tra, kiểm chứng và bảo trì. - Có tài liệu mô tả yêu cầu, điều kiện kiểm thử, vận hành, bảo trì với chất lượng cao. Tính dễ hiểu ngày càng trở thành chỉ tiêu quan trọng với phần mềm. Tuy nhiên để xây dựng phầm mềm tốt ta phải chú ý các điểm sau: ■ Không có phương pháp mô tả rõ ràng định nghĩa yêu cầu của người dùng, khi bàn giao sản phẩm dễ phát sinh những trục trặc. ■ Với những phần mềm có quy mô lớn, tư liệu đặc tả cố định thời gian dài, sẽ khó đáp ứng nhu cầu thay đổi của người dùng một cách kịp thời trong thời gian đó. ■ Nếu không có phương pháp luận thì chất lượng phần mềm sẽ suy giảm. ■ Nếu không có chuẩn về tư liệu quy trình sản xuất phần mềm thì những đặc tả không rõ ràng sẽ làm giảm chất lượng phần mềm. ■ Nếu không kiểm thử tính đúng đắn của phần mềm ở từng giai đoạn mà chỉ kiểm tra giai đoạn cuối, khi đó nếu phát hiện ra lỗi thì bàn giao sản phẩm không đúng hạn. ■ Coi trọng lập trình hơn thiết kế làm cho chất lượng phần mềm giảm. ■ Coi thường tái sử dụng phần mềm làm cho năng suất lao động giảm. ■ Phần lớn trong quy trình phát triền phần mềm do con người thực hiện cũng làm năng suất lao động giảm. ■ Không chứng minh tính đúng đắn của phần mềm làm giảm độ tin cậy của phần mềm. ■ Chuẩn một phần mềm tốt không thể đo được một cách định lượng, do vậy không thể đánh giá được một hệ thống đúng đắn hay không. ■ Khi đầu tư nhân lực lớn vào bảo trì sẽ làm giảm hiệu suất lao động của nhân viên. ■ Công việc bảo trì kéo dài làm giảm chất lượng của tư liệu và ảnh hưởng xấu đến các công việc khác. ■ Quản lý dự án lỏng lẻo kéo theo quản lý lịch trình cũng không rõ ràng. 11 Không có tiêu chuẩn để ước lượng nhân lực và dự toán sẽ làm kéo dài thời hạn vượt kinh phí của dự án. 1.4. Ứng dụng phần mềm Phần mềm có thể được áp dụng trong bất kỳ tình huống nào bao gồm một tập các bước thủ tục (như một thuật toán) đã được xác định trước (các phần mềm ngoại lệ với quy tắc này là các phần mềm hệ chuyên gia và các phần mềm mạng nơron). Nội dung thông tin và tính tất định là các nhân tố quan trọng trong việc xác định bản chất ứng dụng của phần mềm. Nội dung thể hiện ý nghĩa và hình dạng của thông tin vào và ra. Tính tất định thông tin cho biết việc tiên đoán trước trật tự và thời gian của thông tin. Các lĩnh vực phần mềm sau sẽ chỉ ra những phạm vi ứng dụng rộng rãi của phần mềm: Phần mềm hệ thống: Phần mềm hệ thống là tập hợp các chương trình được viết để phục vụ cho chương trình khác. Phần mềm hệ thống (trình biên dịch, trình soạn thảo, các tiện ích quản lý tệp...) xử lý các cấu trúc thông tin phức tạp nhưng xác định. Các ứng dụng hệ thống khác (như thành phần hệ điều hành, bộ xử lý viễn thông) có dữ liệu thường không xác định. Lĩnh vực phần mềm hệ thống được đặc trưng chủ yếu bởi tương tác với hệ thống máy tính; sử dụng nhiều trong các hệ thống nhiều người dùng, thao tác tương tranh đòi hỏi lập lịch, dùng chung tài nguyên và các quản lý tiến trình phức tạp; cấu trúc dữ liệu phức tạp và nhiều giao diện ngoài. Phần mềm thời gian thực: Phần mềm điều phối, phân tích, kiểm soát các sự kiện của thế giới thực khi chúng xuất hiện gọi là phần mềm thời gian thực. Các yếu tố của phần mềm thời gian thực bao gồm một thành phần thu thập dữ liệu để thu thập và định dạng thông tin từ môi trường bên ngoài, một thành phần phân tích biến đổi thông tin theo yêu cầu của ứng dụng, một thành phẩn kiếm soát/đưa ra để đáp ứng với môi trường bên ngoài, một thành phần điều phối để điều hoà các thành phần khác sao cho có thể duy trì đáp ứng thời gian thực hiện hình. Hệ thống thời gian thực phải đáp ứng những ràng buộc thời gian chặt chẽ. Phần mềm nghiệp vụ: Xử lý thông tin nghiệp vụ là lĩnh vực ứng dụng phần mềm lớn nhất. Các hệ thống rời rạc (như tính lương, kế toán thu/chi, quản lý kho) đã phát triển thành các phần mềm hệ thông tin quản lý thâm nhập vào một hay nhiều cơ sở dữ liệu lớn chứa thông tin nghiệp vụ. Những ứng dụng trong lĩnh vực này cấu trúc lại dữ liệu hiện có theo cách thuận tiện cho các thao tác nghiệp vụ hay quản lý. Bên cạnh các ứng dụng xử lý dữ liệu quy ước, các ứng dụng phần mềm nghiệp vụ còn bao gồm cả các tính toán tương tác (như xử lý các giao dịch cho các điểm bán hàng). Phần mềm khoa học và công nghệ: Phần mềm khoa học và công nghệ được đặc trưng bởi các thuật toán ‘‘máy nghiền số”. Các ứng dụng mở rộng từ thiên văn cho đến núi lửa, từ phân tích về ô tô cho tới sự biến động quỹ đạo tàu con thoi, từ sinh học phân tử đến chế tạo tự động. Tuy nhiên, những ứng dụng mới trong lĩnh vực khoa học và công nghệ đang “di chuyển nhanh” ra khỏi các thuật ngữ quy ước. Thiết kế có sự trợ giúp của máy tính (CAD), mô phỏng hệ thống và những ứng dụng tương tác khác đã bắt đầu kế tục các đặc trưng thời gian thực và thậm chí cả phần mềm hệ thống. Phần mềm nhúng: Các sản phẩm thông minh đã trở nên thông dụng. Phần mềm nhúng nằm trong bộ nhớ chỉ đọc và được dùng để điều khiển các sản phẩm và 12 các hệ thống cho người tiêu dùng và thị trường công nghiệp. Phần mềm nhúng có thể thực hiện các chức năng rất giới hạn như điều khiển bàn phím cho lò vi sóng hay đưa ra các khả năng điều khiển và vận hành như chức năng số hoá trong ô tô, kiểm tra xăng, hiển thị bảng đồng hồ, hệ thống phanh... Phần mềm máy tính cá nhân: Xử lý văn bản, đồ họa máy tính, quản trị cơ sở dữ liệu, các ứng dụng tài chính cá nhân và nghiệp vụ, mạng bên ngoài hay thâm nhập cơ sở dữ liệu chỉ là một số lĩnh vực trong hàng trăm ứng dụng, Trong thực tế, phần mềm máy tính cá nhân biểu thị cho một số thiết kế giao diện người - máy được cải tiến nhiều nhất trong các phần mềm, Phần mềm trí tuệ nhân tạo (AI): Phần mềm trí tuệ nhân tạo dùng các thuật toán phi số để giải quyết các vấn đề phức tạp mà tính toán hay phân tích trực tiếp không quản lý được. Hiện nay lĩnh vực trí tuệ nhân tạo hoạt động mạnh nhất là các hệ chuyên gia, còn gọi là các hệ cơ sở tri thức. Tuy nhiên, các lĩnh vực áp dụng khác của phần mềm trí tuệ nhân tạo còn là nhận dạng (hình ảnh và tiếng nói), chứng minh định lý và trò chơi. Trong những năm gần đây, một nhánh mới của phần mềm trí tuệ nhân tạo gọi là mạng nơron nhân tạo, đã phát triển. Mạng nơron mô tả cấu trúc việc xử lý trong não bộ và cuối cùng tạo ra lớp phần mềm mới có thể nhận dạng các mẫu phức tạp và học từ “kinh nghiệm quá khứ”. 2. Công nghệ phần mềm Mục tiêu: Nắm được các định nghĩa công nghệ phần mềm. Định nghĩa công nghệ phân mềm Có nhiều định nghĩa công nghệ phần mềm được đưa ra: Bauer (1969): Công nghệ phần mềm là việc thiết lập và sử dụng các nguyên lý công nghệ đúng đắn để thu được phần mềm vừa kinh tế, tin cậy vừa làm việc hiệu quả trên các máy thực. Pamas (1987): Công nghệ phần mềm là việc xây dựng phần mềm nhiều phiên bản bởi nhiều người. Ghezzi (1991): Công nghệ phần mềm là một lĩnh vực của khoa học máy tính, liên quan đến xây dựng các hệ thống phần mềm vừa lớn vừa phức tạp bởi một hay một số nhóm kỹ sư. IEEE (1993) : Công nghệ phần mềm là: 1. Việc áp dụng phương pháp tiếp cận có hệ thống, bài bản và được lượng hoá trong phát triển vận hành và bào trì phần mềm. 2. Nghiên cứu các phương pháp tiếp cận nói trên. Pressman (1995): Công nghệ phần mềm là sự phát triển của công nghệ phần cứng và hệ thống. Nó là một tập gồm ba yếu tố chủ chốt: Phương pháp, công cụ và thủ tục giúp người quản lý kiểm soát được tiến trình phát triển phần mềm và cung cấp cho người hành nghề một nền tảng để xây dựng phần mềm chất lượng cao có hiệu quả. Các phương pháp công nghệ phần mềm đưa ra các ‘‘cách làm” về mặt kỹ thuật để xây dựng phần mềm. Các phương pháp này bao gồm một phạm vi các nhiệm vụ, bao gồm: Lập kế hoạch và ước lượng dự án, phân tích yêu cầu hệ thống và phần mềm, thiết kế cấu trúc dữ liệu, kiến trúc chương trình và thủ tục thuật toán, mã hoá, kiểm thử và bảo trì. Các phương pháp cho kỹ nghệ phần mềm thường đưa ra các ký pháp đồ hoạ hay hướng ngôn ngữ đặc biệt và đưa ra một tập tiêu chuẩn về chất lượng phần mềm. Các công cụ công nghệ phần mềm cung cấp sự hỗ trợ tự động hay bán tự động 13 cho các phương pháp. Ngày nay đã có các công cụ hỗ trợ cho từng phương pháp được nêu trên. Khi các công cụ được tích hợp đến mức thông tin do công cụ này tạo ra có thể được dùng cho các công cụ khác thì hệ thống hỗ trợ cho việc phát triển phần mềm được thiết lập và còn được gọi là công nghệ phần mềm có sự trợ giúp của máy tính CASE. CASE: tổ hợp phần mềm, phần cứng và cơ sở dữ liệu kỹ nghệ phần mềm (cấu trúc dữ liệu chứa các thông tin quan trọng về việc phân tích, thiết kế, mã hoá và kiểm thử) để tạo ra môi trường kỹ nghệ phần mềm, điều này tương tự như thiết kế có máy tính hỗ trợ/kỹ nghệ có máy tính hỗ trợ (CAD/CASE) cho phần cứng. Các thủ tục công nghệ phần mềm là chất keo dán các phương pháp và công cụ lại với nhau, làm cho chúng được sử dụng hợp lý và đúng hạn trong việc phát triển phần mềm máy tính. Thủ tục xác định trình tự các phương pháp sẽ được áp dụng, những sản phẩm cần bàn giao (tài liệu, báo cáo, mẫu...) cần cho việc kiểm soát để đảm bảo chất lượng và điều hoà thay đổi, xác định những cột mốc để cho người quản lý phần mềm nắm được tiến độ. CÂU HỎI VÀ BÀI TẬP 1. Định nghĩa phần mềm.? 2. Các đặc tính của phần mềm.? 3. Thế nào là một phần mềm tốt.? 4. Ứng dụng của phần mềm? 5. Công nghệ phần mềm là gì?. 14 CHƯƠNG 2: MỘT SỐ MÔ HÌNH VÒNG ĐỜI PHÁT TRIỂN PHẦN MỀM Mã chương: MHCNTT 18.2 Mục tiêu: Sau khi học xong bài học này, sinh viên có khả năng: - Nắm được cách giai đoạn của vòng đời phần mềm - Nắm được quy trình phát triển phần mềm - Hiểu được một số mô hình vòng đời phát triển phần mềm - Nêu được đặc trưng cơ bản và cách thức thực hiện của một số mô hình vòng đời phát triển phần mềm. - Trình bày được các mô hình vòng đời phát triển phần mềm. - Phân biệt được ưu nhược điểm của mỗi mô hình. 1. Các khái niệm cơ bản Mục tiêu: - Nắm được cách giai đoạn của vòng đời phần mềm, quy trình phát triển phần mềm 1.1. Vòng đời phần mềm Vòng đời phần mềm là thời kỳ tính từ khi phần mềm được sinh ra cho đến khi chết đi (từ lúc hình thành đáp ứng yêu cầu, vận hành bảo dưỡng cho đến khi loại bỏ không được sử dụng). Quy trình phát triển phần mềm bao gồm 3 giai đoạn chính: Xác định, phát triển và bảo trì. Ba giai đoạn này xuất hiện trong tất cá các công việc phát triển phần mềm, không phụ thuộc vào miền ứng dụng, cỡ dự án hay độ phức tạp. ■ Giai đoạn xác định : Trong giai đoạn xác định, người phát triển phần mềm tập trung vào xác định thông tin nào cần được xử lý, chức năng và hiệu năng nào cần có, giao diện nào cần được thiết lập, ràng buộc thiết kế nào hiện có và tiêu chuẩn hợp lệ nào cần có để xác định ra một hệ thống thành công. Yêu cầu chủ chốt của hệ thống và phần mềm được xác định. Mặc dù các phương pháp được áp dụng trong giai đoạn xác định thay đổi tuỳ theo khuôn cảnh công nghệ phần mềm, nhưng có ba bước luôn xuất hiện dưới dạng: Phân tích hệ thống-. Xác định ra vai trò của từng phần từ trong hệ thống dựa trên máy tính, chỉ ra vai trò của phần mềm. Lập kế hoạch dự án phần mềm: Khi phạm vi của phần mềm được thiết lập, rủi ro được phân tích, tài nguyên được cấp phát, chi phí được ước lượng thì phải xác định nhiệm vụ công việc và lập lịch. Phân tích yêu cầu: Phạm vi được xác định cho phần mềm sẽ đưa ra chiều hướng nhưng cần phải có thêm việc xác định chi tiết lĩnh vực thông tin và chức năng trước khi công việc có thể bắt đầu. ■ Giai đoạn phát triển : Trong khi xác định, người phát triển cố gắng xác định cách cấu trúc dữ liệu và kiến trúc phần mềm cần được thiết kế, cách các chi tiết thủ tục được cài đặt, cách dịch thiết kế vào ngôn ngữ lập trình hay ngôn ngữ phi thủ tục và cách thực hiện kiểm thử. Phưong pháp được áp dụng trong giai đoạn phát triển sẽ thay đổi nhưng có 3 bước đặc thù bao giờ cũng xuất hiện dưới dạng: Thiết kế phần mềm: Thiết kế dịch các yêu cầu về phần mềm thành một tập hợp các biểu diễn (dựa trên đồ hoạ, bảng hay ngôn ngữ) mô tả cấu trúc dữ liệu, kiến trúc, thủ tục thuật toán và đặc trưng giao diện. 15 Mã hoá: Các biểu diễn thiết kế phải được dịch thành ngôn ngữ nhân tạo (ngôn ngữ có thể là ngôn ngữ lập trình quy ước hoặc ngôn ngữ phi thủ tục dùng trong ngôn ngữ thế hệ 4 - 4GT) mà kết quả sẽ tạo ra là các lệnh thực hiện được trên máy tính. Bước mã hoá thực hiện việc này. Kiểm thử phần mềm: Mỗi khi phần mềm đã được cài đặt dưới dạng mã máy thực hiện được cần phải kiểm thử nó để phát hiện các khiếm khuyết khi vận hành, trong logic và trong cài đặt. ■ Giai đoạn bảo trì : Tập trung vào những thay đổi gắn với việc sửa lỗi, thích ứng khi môi trường phần mềm tiến hoá và nâng cao do yêu cầu người dùng. Giai đoạn bảo trì áp dụng lại các bước của giai đoạn xác định và phát triển nhưng làm việc đó trong hoàn cảnh phần mềm hiện có. Có ba kiểu thay đổi gặp phải trong giai đoạn bảo trì: Sửa đổi: Phần mềm luôn có lỗi tiềm tàng. Trong quá trình sử dụng, cho dù các hoạt động bảo đảm chất lượng phần mềm là tốt nhất, khách hàng vẫn có thể sẽ phát hiện ra khiếm khuyết trong phần mềm. Bảo trì sửa đổi thay đổi phần mềm để sửa các khiếm khuyết. Thích nghi: Qua thời gian, môi trường ban đầu để phát triển phần mềm có thể thay đổi. Bảo trì để thích nghi thực hiện việc sửa đổi phần mềm để nó thích hợp với những thay đổi môi trường bên ngoài. Nâng cao:. Khi phần mềm được dùng, khách hàng/người dùng sẽ nhận ra những chức năng phụ có lợi. Bảo trì hoàn thiện mở rộng phần mềm ngoài các yêu cầu chức năng gốc của nó. Bên cạnh những hoạt động cơ bản này, một số công ty còn xem xét tới kỹ nghệ ngược. Dùng một tập riêng các công cụ CASE, phần mềm cũ được kỹ nghệ hoá ngược lại để cho người dùng có thể hiểu và cải tiến sự làm việc bên trong của nó. 1.2. Quy trình phát triển phần mềm Một quy trình phát triển phần mềm có thể được mô tá như hình 2.1. Common Process Framework Framework Activities Umbrella activities Hình 2.1.Quy trình phần mềm Một khung quy trình chung (Common Process Framework) được thiết lập bằng cách xác định một số các hoạt động khung (Frame Activities) có khả năng áp dụng cho mọi dự án phần mềm không phân biệt kích cỡ, độ phức tạp. Tập nhiệm vụ công việc (task sets) - tập hợp các công việc công nghệ phần mềm, các cột mốc dự án, sản phẩm và các điểm bảo đảm chất lượng - cho phép các hoạt động khung thích ứng với các đặc tính của dự án phần mềm và yêu cầu của đội dự án. Cuối cùng các hoạt động bao trùm (umbrella activities) được coi như các bảo đảm cho chất lượng phần mềm, quản lý cấu hình phần mềm, bảo trì - bao trùm mô hình quy 16 trình. Các hoạt động bao trùm độc lập với bất cứ hoạt động khung nào và diễn ra trong suốt quy trình. 2. Một số mô hình vòng đời phát triển phần mềm Mục t... Một vài hướng dẫn đơn giản sau có thể trợ giúp cho việc suy ra biểu đồ luồng dữ liệu: 1. Biểu đồ luồng dữ liệu mức 0 nên mô tả chỉ là một vòng tròn phần mềm /hệ thống. 2. Đầu vào và đầu ra chính cần được chú thích cẩn thận. 3. Việc làm mịn dần nên bắt đầu từ việc cô lập các tiến trình, khoản mục dữ liệu và kho ứng cử viên được biểu diễn ở mức tiếp. 4. Tất cả các mũi tên và hình tròn nên được gắn nhãn bằng những tên có ý nghĩa. 5. Phải duy trì được tính liên tục luồng thông tin từ mức này sang mức kia. 6. Mỗi lúc chỉ làm mịn một hình tròn. Có một khuynh hướng tự nhiên hay làm phức tạp hoá biểu đồ luồng dữ liệu. Điều này xuất hiện khi người phân tích chỉ ra nhiều chi tiết quá sớm hay biểu diễn các khía cạnh thủ tục của phần mềm thay vì luồng thông tin. Trong DFD mức 0, các tác nhân ngoài chủ yếu tạo ra thông tin cho hệ thống và tiêu thụ các thông tin do hệ thống sinh ra. Các mũi tên có nhãn biểu thị cho khoản mục dữ liệu hợp thành, tức là các dữ liệu thực là một tập hợp của nhiều khoản mục dữ liệu phụ. DFD mức 0 được mở rộng thành DFD mức 1. Một cách tiếp cận đơn giản và hiệu quả là thực hiện “phân tích văn phạm”. Tức là, chúng ta cô lập tất cả các danh từ và cụm danh từ, động từ và cụm động từ trong lời thoại trên. Tất cả các danh từ đều hoặc là các tác nhân ngoài, các khoản mục dữ liệu, các điều khiển hay các kho dữ liệu. Do đó, bằng cách thực hiện phân tích văn phạm lời thuật về xử lý cho một hình tròn ở bất kỳ mức DFD nào chúng ta có thể tạo ra rất nhiều thông tin có ích về cách tiến hành làm mịn cho mức tiếp theo. Các tiến trình được biểu diễn ở DFD mức 1 có thể được làm mịn thêm ở các mức thấp hơn. Việc làm mịn cho các DFD tiếp tục cho đến khi hình tròn thực hiện một chức năng đơn giản, tức là cho tới khi tiến trình được biểu diễn bởi một vòng tròn thực hiện một chức năng dễ dàng, được cài đặt như một thành phần của chương trình. Trong phân tích yêu cầu, người kỹ sư phần mềm có thể phát hiện một số khía cạnh nào đó của hệ thống sẽ thay đổi hay sẽ được nâng cao trong tương lai hoặc chưa được xác định rõ. Một cách khác, người phân tích có thể làm việc trên phần mềm hiện có để tìm ra sự thay đổi. Trong cả hai trường hợp, biểu đồ luồng dữ liệu cho phép dễ dàng cô lập lĩnh vực thay đổi. Bằng việc hiểu rõ luồng thông tin đi qua biên giới lĩnh vực thay đổi. người ta có thể có chuẩn bị tốt cho việc thay đổi trong tương lai, hay có thể tiến hành thay đổi hiện tại mà không làm đảo lộn các phần tử khác của hệ thống. Tạo ra mô hình luồng điều khiển 30 Đối với nhiều kiểu ứng dụng xử lý dữ liệu, biểu đồ luồng dữ liệu là tất cả những điều cần thiết để có được cái nhìn ý nghĩa đối với các yêu cầu phần mềm. Tuy nhiên, như đã lưu ý, tồn tại một lớp ứng dụng rộng rãi hơn, được “điều khiển” bởi các sự kiện thay vì dữ liệu, tạo ra thông tin điều khiển chứ không chỉ là báo cáo hay hiển thị, xử lý thông tin với mối quan tâm chủ yếu về thời gian và hiệu năng. Những ứng dụng như vậy đòi hỏi mô hình luồng điều khiển CFD bên cạnh biểu đồ luồng dữ liệu. Để xét duyệt cách tiếp cận CFD, biểu đồ luồng dữ liệu được loại bỏ mọi mũi tên luồng dữ liệu. Các sự kiện và các khoản mục điều khiển được bổ sung vào biểu đồ và một cửa sổ được vẽ trong đặc tả điều khiển. Để chọn các sự kiện ta có hướng dẫn sau: ■ Liệt kê tất cả các cảm biến mà phần mềm đọc. ■ Liệt kê tất cả các điều kiện ngắt. ■ Liệt kê tất cả các “chuyển mạch” mà thao tác viên dùng. ■ Liệt kê tất cả các điều kiện dữ liệu. ■ Gợi lại việc phân tích danh từ - động từ áp dụng cho lời thuật xử lý xét lại tất cả các "khoản mục điều khiển" như đầu vào/đầu ra. ■ Mô tả hành vi của hệ thống bằng cách xác định trạng thái của nó. Xác định cách đạt đến từng trạng thái và định nghĩa phép chuyển giữa các trạng thái. ■ Tập trung vào những bỏ sót có thể - một lỗi rất thông thường trong xác định các điều khiển như hỏi "Liệu còn cách nào khác để tới hay ra khỏi trạng thái này không?". Đặc tả điều khiển (Control specification) Đặc tả điều khiển (CSPEC) biểu diễn cho hành vi của hệ thống theo hai cách khác nhau. CSPEC chứa một biểu đồ chuyển trạng thái (STD) là đặc tả tuần tự cho hành vi. Nó cũng có thể chứa một bảng kích hoạt chương trình (PAT) - một đặc tả tổ hợp cho hành vi. Bằng cách nghiên cứu STD người kỹ sư phần mềm có thể xác định hành vi của hệ thống và điều quan trọng hơn là xác định được liệu có lỗ hổng nào trong hành vi được đặc tả không. Một kiểu biểu diễn hành vi khác là bảng kích hoạt tiến trình PAT. PAT biểu thị cho thông tin chứa trong hoàn cảnh của tiến trình, không phải là trạng thái. Tức là bảng chỉ ra tiến trình nào (hình tròn nào) trong mô hình luồng sẽ được gọi đến khi sự kiện xuất hiện. PAT được dùng như bảng hướng dẫn cho người thiết kế, người phải xây dựng cách điều hành kiếm soát các tiến trình được biểu diễn ở mức này. CSPEC mô tả hành vi của hệ thống, nhưng nó không cung cấp bất kỳ thông tin nào về cách làm việc của các tiến trình được xem như kết quả của hành vi này Đặc tả tiến trình (Process specification) Đặc tả tiến trình (PSPEC) được dùng để mô tả cho các tiến trình mô hình luồng xuất hiện ở mức cuối của việc làm mịn. Nội dung của đặc tả tiến trình bao gồm đoạn văn tường thuật, ngôn ngữ thiết kế chương trình (PĐL) mô tả thuật toán xử lý, phương trình toán học, bảng, biểu đồ hay lược đồ. Bằng cách đưa PSPEC đi kèm với từng hình tròn trong mô hình luồng, người kỹ sư phần mềm tạo ra một “mini đặc tả" được dùng như bước đầu tiên trong việc tạo ra bản đặc tả các yêu cầu phần mềm và dùng như một hướng dẫn cho việc thiết kế thành phần chương trình sẽ cài đặt cho tiến trình. 31 4.3. Phân tích hướng đối tượng Khi xây dựng một sản phẩm hay một hệ thống mới, chúng ta mô tả nó như thế nào để thích hợp với công nghệ phần mềm hướng đối tượng? Các đối tượng phù hợp là gì? Chúng liên hệ với nhau như thế nào? Các đối tượng ứng xử như thế nào trong ngữ cảnh của hệ thống? Chúng ta mô tả hoặc mô hình các vấn đề như thế nào để tạo ra được một thiết kế có hiệu quả? Mỗi câu hỏi trên đều có thể trả lời trong ngữ cảnh phân tích hướng đối tượng (OOA). Để xây dựng một mô hình phân tích 5 nguyên tắc sau được áp dụng: 1. Miền thông tin được mô hình. 2. Chức năng module được mô tả. 3. Mô hình hành vi được mô tả. 4. Các mô hình được chia nhỏ để chi tiết hơn. 5. Các mô hình ban đầu mô tả bản chất của vấn đề, các mô hình về sau cung cấp chi tiết thực hiện. Mục đích của OOA là định nghĩa các lớp (và các mối quan hệ, các hành vi liên kết nói chung) phù hợp với vấn đề cần giải quyết. Để thực hiện điều này phải thực hiện các công việc sau: 1. Các yêu cầu cơ bản của người sử dụng phải được liên lạc giữa khách hàng và kỹ sư phần mềm. 2. Các lớp phải được xác định (các phương thức và các thuộc tính phải được định nghĩa). 3. Một cây lớp phải được mô tả. 4. Mối quan hệ đối tượng tới đối tượng phải được mô tả. 5. Một hành vi các đối tượng phải được mô hình hoá. 6. Các công việc từ 1 đến 5 được lặp đi lặp lại cho đến khi mô hình được hoàn tất. Mục đích của phân tích hướng đối tượng là phát triển một tập các mô hình mô tả hệ thống phần mềm máy tính như nó hoạt động để thỏa mãn các yêu cầu người dùng đã được xác định. OOA giống như các phương pháp phân tích thông thường khác xây dựng một mô hình phân tích nhiều phần để đạt mục tiêu trên Cách tiếp cận thông thường và cách tiếp cận hướng đối tượng Phân tích có cấu trúc đã đưa ra một khung nhìn đầu vào – xử lý - đầu ra của yêu cầu. Dữ liệu được xem xét riêng rẽ từ các xử lý chuyển dữ liệu 1 hành vi của hệ thống, mặc dù rất quan trọng chỉ chiếm vị trí thứ yếu trong phân tích có cấu trúc. Fichman và Kemerer đã gợi ý 11 "hướng mô hình" được sử dụng để so sánh phương pháp thiết kế thông thường và phương pháp thiết kế hướng đối tượng: 1. Xác định/phân loại các thực thể. 2. Mô tả chung và toàn bộ mối quan hệ thực thể. 3. Các mối quan hệ thực thể khác. 4. Mô tả thuộc tính các thực thể. 5. Phân chia mô hình phạm vi rộng. 6. Trạng thái và chuyển giữa các trạng thái. 7. Mô tả chi tiết các hàm. 8. Phân tích trên xuống. 9. Dãy xử lý end - to - end. 10. Xác định các dịch vụ thực hiện riêng. 11. Giao tiếp thực thể (bằng thông điệp hay bằng sự kiện). 32 Các phương pháp phân tích hướng đối tượng Phương pháp Booch Phương pháp Booch bao gồm hai quy trình phát triển vi mô và vĩ mô. Mức vi mô xác định tập các nhiệm vụ phân tích được áp dụng lại cho các bước trong quy trình vĩ mô. Do đó, cách tiếp cận tiến hoá được duy trì. Một phác thảo của quy trình phát triển vi mô do Booch đề nghị như sau: ■ Xác định các lớp và đối tượng. - Đưa ra các lớp ứng viên. - Quản lý phân tích hành vi. - Xác định kịch bản thích hợp. - Xác định các thuộc tính và phương thức cho mỗi lớp. ■ Xác định ngữ nghĩa của các lớp và đối tượng - Chọn kịch bản và phân tích. - Phân công trách nhiệm cho các hành vi kế thừa của lớp và đối tượng. - Chọn đối tượng và liệt kê vai trò và nhiệm vụ của nó. - Xác định phương thức thỏa mãn nhiệm vụ. - Tìm kiếm sự cộng tác giữa các đối tượng. ■ Xác định mối quan hệ giữa các lớp và đối tượng. - Xác định tính phụ thuộc tồn tại giữa các lớp. - Mô tả vai trò của mỗi đối tượng cụ thể. - Kiểm tra bảng các kịch bản. ■ Quản lý các hoạt động điều chỉnh thích hợp. - Tạo ra biểu đồ thích hợp cho công việc được quản lý bên trên. - Xác định phân cấp lớp khi thích hợp. - Thực hiện nhóm dựa trên sự tương đồng lớp. ■ Thực thi các kép và đối tượng (trong ngữ cảnh OOA, nó mang ý nghĩa hoàn thành mô hình phân tích). Phương pháp Coad và Yourdon Một phác thảo của quy trình phát triển do Coad và Yourdon đề nghị như sau: ■ Xác định đối tượng sử dụng tiêu chuẩn “tìm kiếm cái gì". ■ Xác định cấu trúc tổng quát - đặc tả. ■ Xác định cấu trúc toàn thể - bộ phận. ■ Xác định chủ đề (mô tả các thành phần hệ thống con). ■ Xác định các thuộc tính ■ Xác định các dịch vụ Phương pháp Jacobson Phương pháp này nhấn mạnh vào các trường hợp sử dụng - mô tả cách người dùng tương tác với sản phẩm hay hệ thống. Một phác thảo của quy trình phát triển do Jacobson đề nghị như sau: ■ Xác định người sử dụng hệ thống và toàn bộ nhiệm vụ của họ. ■ Xây dựng mô hình yêu cầu. - Xác định các tác nhân và trách nhiệm. - Xác định trưởng hợp sử dụng cho mỗi tác nhân. - Chuẩn bị khung nhìn ban đầu của đối tượng hệ thống và các quan hệ. - Xem xét lại mô hình sử dụng trường hợp sử dụng như một kịch bản để kiểm tra. ■ Xây dựng mô hình phân tích 33 - Xác định đối tượng giao diện sử dụng thông tin tác nhân tương tác. - Tạo khung nhìn cấu trúc của đối tượng giao diện. - Mô tả hành vi đối tượng. - Cô lập hệ thống con và mô hình cho chúng. - Xem lại mô hình sử dụng trường hợp sử dụng như một kịch bản để kiểm tra. Phương pháp Rambaugh Kỹ thuật mô hình đối tượng (OM 1) cho phân tích, thiết kế hệ thống và thiết kế mức đối tượng. Các hoạt động phân tích tạo ra 3 mô hình: mô hình đối tượng (mô tả các đối tượng, các lớp, cây và mối quan hệ), mô hình động (mô tả các hành vi của đối tượng và hệ thống) và mô hình chức năng (mô tả giống như DFD mức cao mô tả các luồng thông tin chuyển qua trong hệ thống). Một phác thảo của quy trình phát triển do Rambaugh đề nghị như sau: ■ Phát triển một bản kê phạm vi vấn đề. ■ Xây dựng một mô hình đối tượng. - Xác định các lớp thích hợp cho vấn đề. - Định nghĩa các thuộc tính và liên kết. - Định nghĩa liên kết đối tượng. - Tổ chức lớp đối tượng sử dụng thừa kế. ■ Phát triển mô hình động. - Chuẩn bị kịch bản. - Xác định sự kiện và phát triển vết các sự kiện cho mỗi kịch bản. - Xây dựng biểu đồ luồng sự kiện. - Phát triển biểu đồ trạng thái. - Xem lại hành vi cho tính nhất quán và sự hoàn chỉnh. ■ Xây dựng một mô hình chức năng cho hệ thống. - Xác định đầu vào và đầu ra. - Sử dụng biểu đồ luồng dữ liệu để mô tả sự chuyển luồng. - Phát triển PSPEC cho mỗi chức năng. - Mô tả ràng buộc và các tiêu chuẩn tối ưu. Phương pháp Wirfs - Brock Phưong pháp này không tạo ra sự khác biệt rõ ràng giữa các công việc phân tích và thiết kế. Thay vào đó, một quá trình tiếp diễn bất đầu khi xác định đặc tả khách hàng và kết thúc khi thiết kế được đề xuất. Một phác thảo của quy trình phát triển do Wirfs - Brock đề nghị như sau: ■ Ước lượng đặc tả khách hàng. ■ Sử dụng phân tích ngữ pháp để rút ra các lớp ứng viên từ đặc tả. ■ Nhóm các lớp để xác định các lớp Cha. ■ Định nghĩa trách nhiệm cho mỗi lớp. ■ Phân công trách nhiệm cho mỗi lớp. ■ Xác định sự cộng tác giữa các lớp dựa trên trách nhiệm. ■ Xây dựng mô tả cây của lớp để chỉ ra mối quan hệ thừa kế ■ Xây dựng một biểu đồ công tác cho hệ thống. Mặc dù các bước tiến hành khác nhau với mỗi phương pháp OOA nhưng toàn bộ quy trình OOA có sự tương tự. Để thực hiện phân tích hướng đối tượng, một kỹ sư hệ thống phải thực hiện các bước sau: ■ Thu nhận các yêu cầu của khách hàng cho hệ thống hướng đối tượng 34 (Object Oriented - 00). - Xác định các kịch bản hay các trường hợp sử dụng. - Xây dựng mô hình yêu cầu. ■ Chọn các lớp, các đối tượng sử dụng các yêu cầu cơ bản như là hướng dẫn. ■ Xác định các thuộc tính và các phương thức cho mỗi đối tượng hệ thống. ■ Xác định cấu trúc và cây cho mỗi lớp tổ chức. ■ Xây dựng mô hình quan hệ đối tượng. ■ Xây dựng mô hình hành vi đối tượng. ■ Xem xét lại các phân tích CÂU HỎI VÀ BÀI TẬP 1. Xác định yêu cầu phần mềm? 2. Phân tích có cấu trúc? 3. Phân tích hướng đối tượng? 4. Các phương pháp phân tích hướng đối tượng? 35 CHƯƠNG 4: THIẾT KẾ PHẦN MỀM Mã chương: MHCNTT 18.4 Mục tiêu: Sau khi học xong bài học này, sinh viên có khả năng: - Nêu được khái niệm và vai trò của thiết kế phần mềm. - Phát biểu được tiến trình để triển khai thiết kế. -Trình bày được các phương pháp thiết kế hệ thống theo hướng chức năng, hướng đối tượng, thiết kế hệ thống thời gian thực, thiết kế giao diện -Vận dụng các phương pháp thiết kế để giải quyết bài toán phần mềm thực tế 1. Tổng quan về thiết kế phần mềm 1.1 Khái niệm và vai trò của thiết kế Thiết kế là bước đầu tiên trong giai đoạn phát triển bất cứ một sản phẩm hay hệ thống công nghệ nào. Nó được định nghĩa là ''tiến trình áp dụng nhiều kỹ thuật và nguyên lý với mục đích xác định một thiết bị, một tiến trình hay một hệ thống dù chi tiết để cho phép thực hiện nó về mặt vật lý’’. Mục tiêu của thiết kế là tạo ra một mô hình hay biểu diễn một thực thể sau này sẽ được áp dụng. Tiến trình phát triển mô hình này dựa trên kinh nghiệm trong việc xây dựng các thực thể tương tự, một tập các nguyên lý và/hoặc các trực cảm hướng dẫn cách tiến triển mô hình này, một tập các tiêu chuẩn để đánh giá chất lượng và một tiến trình lặp lại để sau đó dẫn tới biểu diễn thiết kế chung cuộc. Thiết kế phần mềm là trung tâm kỹ thuật của tiến trình công nghệ phần mềm và được áp dụng cho khuôn cảnh phát triển phần mềm bất kỳ. Khi các yêu cầu phần mềm được phân tích và đặc tả thì thiết kế phần mềm là một trong 3 hoạt động - thiết kế, lập trình và kiểm thử - những hoạt động cần để xây dựng và kiểm chứng phần mềm. Luồng thông tin trong giai đoạn kỹ thuật được minh hoạ trên hình 6.1. Các yêu cầu phần mềm được biểu thị bởi mô hình thông tin, chức năng và hành vi, là đầu vào cho bước thiết kế. Sử dụng một trong các phương pháp thiết kế, tạo thiết kế dữ liệu, thiết kế kiến trúc, thiết kế thủ tục. Thiết kế dữ liệu chuyển mô hình lĩnh vực thông tin đã được tạo ra trong phân tích thành các cấu trúc dữ liệu cần thiết cho việc cài đặt phần mềm sau này. Thiết kế kiến trúc định nghĩa một mối quan hệ giữa các thành phần cấu trúc chính của chương trình. Thiết kế thủ tục biến đổi các thành phần cấu trúc thành mô tả thủ tục phần mềm. Chương trình gốc sẽ được sinh ra sau đó việc kiểm thử được thực hiện để tích hợp và làm hợp lệ phần mềm. Thiết kế phần mềm là một tiến trình qua đó các yêu cầu được dịch thành một biểu diễn phần mềm. Ban đầu biểu diễn mô tả quan điểm của toàn bộ phần mềm. Việc làm mịn tiếp sau dẫn tới một biểu diễn thiết kế rất gần với chương trình gốc. Theo quan điểm quản lý dự án, thiết kế phần mềm được tiến hành theo hai bước. Thiết kế sơ bộ quan tâm tới việc dịch các yêu cầu thành kiến trúc dữ liệu và phần mềm. Thiết kế chi tiết tập trung vào làm mịn biểu diễn kiến trúc để dẫn tới cấu trúc dữ liệu chi tiết và biểu diễn thuật toán cho phần mềm. Trong phạm vi thiết kế sơ bộ và chi tiết, xuất hiện các hoạt động khác nhau. Bên cạnh việc thiết kế dữ liệu, kiến trúc và thủ tục, nhiều ứng dụng hiện đại còn có hoạt động thiết kế giao diện phân biệt. Thiết kế giao diện lập ra cách bố trí và cơ chế tương tác cho tương tác người - máy. 36 Khái niệm thiết kế được định nghĩa theo 2 cách sau: · Thiết kế là quy trình định nghĩa ra kiến trúc, thành phần, interfaces và các thuộc tính khác của một hệ thống hoặc một thành phần. Trong quy trình này, yêu cầu phần mềm được phân tích để đưa ra một cấu trúc của phần mềm làm cơ sở để làm ra phần mềm. · Thiết kế là kết quả của một quá trình. Nó mô tả kiến trúc của một phần mềm như là phần mềm được phân rã và tổ chức như thế nào trong các thành phần và các interfaces giữa các thành phần như thế nào. Nó cũng có thể mô tả các thành phần ở mức chi tiết cho phép có thể xây dựng được phần mềm. Thiết kế phần mềm đóng vai trò quan trọng trong suốt quá trình thiết kế, những kỹ sư phần mềm sẽ đề xuất các mô hình tạo thành loại kế hoạch chi tiết cho giải pháp để có thể thực hiện được. Chúng ta có thể phân tính và đánh giá những mô hình này có hay không phù hợp với những yêu cầu khác nhau. Chúng ta có thể sử dụng kiểm tra và thẩm định thay thế những giải pháp và những đánh đổi (tradeoffs). Cuối cùng chúng ta sử dụng những mô hình kết quả để lên kế hoạch các hoạt động phát triển tiếp theo như là: thẩm định và kiểm thử hệ thống, thêm vào đó sử dụng chúng như là đầu vào hay là điểm bắt đầu của xây dựng và kiểm thử phần mềm. Trong danh sách chuẩn của vòng đời phát triển phần mềm như ISO/IEC/IEEE Software Life Cycle Process, thiết kế phần mềm bao gồm 2 hoạt động tương ứng với phân tích yêu cầu phần mềm và xây dựng phần mềm: · Thiết kế kiến trúc (còn được gọi là thiết kế mức cao): là phát triển mức kiến trúc cao nhất và đưa ra cách tổ chức phần mềm và chỉ ra các thành phần khác nhau trong phần mềm 37 · Thiết kế chi tiết: chỉ ra chi tiết và đầy đủ về thành phần tạo điều kiện xây dựng phần mềm trong pha sau đó Đầu ra của thiết kế phần mềm sẽ được sử dụng cho quá trình xây dựng và kiểm thử nên việc đánh giá một thiết kế có phù hợp hay không rất quan trọng, nếu một thiết kế sai sẽ dẫn đến tất cả các quá trình sau đó cũng sai và cần phải chỉnh sửa nếu thiết kế được chỉnh sửa. 1.2. Tiến trình thiết kế Thiết kế có cấu trúc cho phép biến đổi thuận tiện từ các biểu diễn thông tin như biểu đồ luồng dữ liệu có trong bản Đặc tả yêu cầu phần mềm sang mô tả về cấu trúc chương trinh. Việc biến đổi từ luồng thông tin sang cấu trúc thông tin được thực hiện như một phần của tiến trình gồm 5 bước: ■ Thiết lập kiểu luồng thông tin. ■ Chi ra biên giới luồng. ■ Ánh xạ DT’D vào cấu trúc chương trình ■ Xác định các cấp bậc điều khiển theo cách tạo nhân to ■ Cấu trúc kết quả được làm mịn bằng cách dùng các phương tiện thiết kế và trực cảm. Khi luồng thông tin là bộ dẫn lái cho cách tiếp cận ánh xạ ở bước 3. 1.3. Chất lượng thiết kế Chất lượng phần mềm là gì? Chất lượng phần mềm là phần mềm có số lượng lỗi chấp nhận được, được phân phối đúng thời hạn và trong ngân sách, đáp ứng các yêu cầu hoặc kỳ vọng, và có thể duy trì được. Tiêu chuẩn ISO 8402-1986 định nghĩa chất lượng là một tổng số các tính năng và đặc điểm của sản phẩm hoặc dịch vụ mang khả năng đáp ứng các nhu cầu đã nêu hoặc ngụ ý. Các khía cạnh chính của phần mềm chất lượng cho khách hàng bao gồm: · Thiết kế đẹp · Chức năng tốt – phần mềm hoạt động tốt · Đáng tin cậy - mức độ sự cố hoặc lỗi chấp nhận được · Tính nhất quán · Bền - kéo dài · Dịch vụ hậu mãi tốt · Giá trị của đồng tiền Thiết kế tốt là gì Sẽ rất quan trọng để có một thiết kế tốt. Ứng dụng hoặc sản phẩm phải đáp ứng tất cả các thông số kỹ thuật yêu cầu và đồng thời nó phải thân thiện với người dùng. Các khách hàng về cơ bản bị thu hút bởi ngoại hình đẹp và phong cách của ứng dụng. Sự kết hợp màu sắc phù hợp, kích thước phông chữ và kiểu dáng của văn bản và nút là rất quan trọng. Chức năng tốt - nó hoạt động tốt Cùng với vẻ ngoài đẹp mắt của ứng dụng hoặc sản phẩm, nó rất quan trọng là chức năng phải còn nguyên vẹn. Tất cả các tính năng và chức năng của chúng nên hoạt động như mong đợi. Không nên có bất kỳ sai lệch nào trong kết quả thực tế và kết quả mong đợi. Đáng tin cậy - mức độ sự cố hoặc thất bại chấp nhận được 38 Sau khi tester đã kiểm tra tất cả các tính năng và chức năng của phần mềm, điều rất quan trọng là ứng dụng hoặc sản phẩm phải đáng tin cậy. Ví dụ: Có một ứng dụng lưu hồ sơ của sinh viên. Ứng dụng này sẽ lưu tất cả các hồ sơ của sinh viên và không nên thất bại sau khi nhập 100 hồ sơ. Điều này được gọi là độ tin cậy. Tính nhất quán Phần mềm nên có tính nhất quán trên toàn bộ ứng dụng hoặc sản phẩm. Phần mềm đơn có thể là đa chiều. Điều rất quan trọng là tất cả các kích thước khác nhau phải hành xử một cách nhất quán. Bền - kéo dài Phần mềm phải bền. Ví dụ: nếu phần mềm đang được sử dụng trong một năm và số lượng dữ liệu đã vượt quá 5000 bản ghi thì không nên thất bại nếu số lượng bản ghi tăng. Sản phẩm hoặc ứng dụng phần mềm nên tiếp tục hoạt động theo cùng một cách mà không có bất kỳ sự phá vỡ chức năng nào. Dịch vụ hậu mãi tốt Sau khi sản phẩm được chuyển đến khách hàng, bảo trì sẽ được đưa vào hình ảnh. Điều rất quan trọng là cung cấp dịch vụ bán hàng tốt để giữ cho khách hàng hài lòng. Ví dụ, nếu sau khi sử dụng sản phẩm trong sáu tháng, khách hàng nhận ra một số thay đổi cho ứng dụng thì những thay đổi đó nên được thực hiện nhanh nhất có thể và nên được gửi đến khách hàng đúng thời gian với chất lượng. Giá trị của đồng tiền Nó luôn luôn quan trọng để cung cấp sản phẩm cho khách hàng có giá trị đồng tiền. Sản phẩm phải đáp ứng các thông số kỹ thuật yêu cầu. Nó nên hoạt động như mong đợi, nên thân thiện với người dùng. Chúng tôi nên cung cấp dịch vụ tốt cho khách hàng. Khác với các tính năng được đề cập trong thông số kỹ thuật yêu cầu, một số chức năng bổ sung có thể được cung cấp cho khách hàng mà họ có thể không nghĩ tới. Những chức năng bổ sung này sẽ làm cho sản phẩm của họ thân thiện hơn và dễ sử dụng hơn. Điều này cũng thêm giá trị đồng tiền. 2. Thiết kế kiến trúc 2.1. Khái niệm và vai trò Một số vấn đề quan trọng phải được xử lý trong khi thiết kế phần mềm. Đặc biệt là những lo ngại về chất lượng phần mềm mà có thể kể đến như: hiệu suất, bảo mật, độ tin cậy, khả năng sử dụng, vv... Một số vấn đề quan trọng khác là làm thế nào để phân rã, tổ chức và đóng gói những thành phần phần mềm. Đây là nguyên tắc cơ bản mà tất các các phương pháp thiết kế phải giải quyết nó bằng cách này hay cách khác. Ngược lại, những vấn đề “liên quan đến các khía cạnh của các hành vi phần mềm mà lại không nằm trong miền ứng dụng mà nằm ở các miền khác có liên quan” Những vấn đề đó thường xuyên chồng chéo với các chức năng của hệ thống và được gọi những khía cạnh mà đa phần không phải là đơn vị phân rã của phần mềm mà là thuộc tính ảnh hưởng đến hiệu suất hoặc ngữ nghĩa của các thành phần một cách có hệ thống. Đồng thời (concurrency) Đồng thời là nhiều việc xảy ra tại cùng một thời điểm. Thiết kế để có tính đồng thời có liên quan đến phân rã phần mềm thành quy trình, nhiệm vụ, quá trình và đối phó với các vấn đề liên quan đến tính hiệu quả, tính nguyên tố, đồng bộ hóa và lập kế hoạch. Thiết kế này đảm bảo dễ phân chia công việc cũng như có thể hoàn thành công việc trong thời gian ngắn nhất. Điều khiển và xử lý các sự kiện 39 Vấn đề thiết kế này liên quan tới làm thế nào tổ chức dữ liệu và dòng dữ liệu cũng như làm thế nào để xử lý các sự kiện tạm thời và phản xạ qua các cơ chế lời gọi ngầm và gọi lại. Dữ liệu bền vững (data persistence) Vấn đề của thiết kế này liên quan tới làm thế nào để xử lý dữ liệu tồn tại lâu dài Phân phối các thành phần Vấn đề của thiết kế này liên quan đến làm thế nào để phân phối các phần mềm trên phần cứng ( bao gồm phần cứng máy tính và phần cứng mạng), làm thế nào các thành phần giao tiếp được với nhau và làm thế nào tầng giữa có thể được sử dụng để đối phó với không tương thích phần mềm. Lỗi và xử lý ngoại lệ và lỗi dung nạp (error and exception handling and fault tolerance) Vấn đề của thiết kế này liên quan đến làm thế nào để phòng chống, chịu đựng và các xử lý lỗi và đối phó với các điều kiện ngoại lệ Tương tác và trình bày (Interaction and presentation) Vấn đề thiết kế này liên quan tới làm thế nào để cấu trúc và tổ chức tương tác với những người dùng và biểu diễn thông tin ( ví dụ, chia giao diện và khung nhìn logic sử dụng hướng tiếp cận MVC) Chú ý rằng chủ đề này không chỉ chi tiết giao diện người dùng, đó là nhiệm vụ của thiết kế giao diện người dùng Bảo mật (sercurity) Thiết kế cho bảo mật liên quan đến làm thế nào để ngăn chặn tiết lộ trái phép, sáng tạo, thay đổi, xóa, hoặc từ chối truy cập đến thông tin từ các nguồn khác. Nó cũng quan tâm làm thế nào để chịu được các cuộc tấn công bảo mật hoặc sự xâm phạm bởi hạn chế thiệt hại, tiếp tục dịch vụ, tốc độ sửa chữa và phục hồi, và thất bại và phục hồi an toàn. Kiểm soát truy cập là một khái niệm an ninh cơ bản và ta cũng nên đảm bảo sử dụng đúng mật mã 2.2. Các mô hình kiến trúc Để tổ chức các hệ thống phần mềm, bạn có thể sử dụng các mẫu kiến trúc phổ biến dưới đây: Kiến trúc phân lớp – Layered (n-tier) Architecture Mẫu kiến trúc này có thể được sử dụng trong các hệ thống có thể được phân tách thành các nhóm gồm nhiều công việc nhỏ. Đặc điểm: · Các lớp khác nhau được xác định trong kiến trúc. Nó bao gồm lớp bên ngoài và bên trong. · Thành phần của lớp ngoài quản lý các hoạt động giao diện người dùng. · Các thành phần thực thi giao diện hệ điều hành ở lớp bên trong. · Các lớp bên trong là lớp ứng dụng, lớp tiện ích và lớp lõi. Kiến trúc hướng sự kiện – Event-driven architecture Nhiều chương trình dành phần lớn thời gian để chờ đợi điều gì đó xảy ra. Điều này đặc biệt đúng đối với các máy tính làm việc trực tiếp với con người. Nhưng nó cũng phổ biến trong các lĩnh vực như mạng. Đôi khi có dữ liệu cần xử lý và những lần khác thì không. Kiến trúc hướng sự kiện giúp quản lý điều này bằng cách xây dựng một đơn vị trung tâm quản lý tất cả dữ liệu. Sau đó, dữ liệu sẽ được đưa đến các modules riêng biệt để xử lý. Kiến trúc hướng đối tượng – Objects based Architecture 40 Nó là một mô hình kiến trúc dựa trên việc phân chia công việc cho một ứng dụng hoặc hệ thống thành các đối tượng có thể tái sử dụng và tự cung cấp. Kiến trúc hướng đối tượng xem một hệ thống phần mềm như một tập hợp các thực thể được gọi là các đối tượng. 3. Thiết kế hệ thống hướng chức năng 3.1. Thiết kế dữ liệu Đây là lối tiếp cận truyền thống của ngành Công nghệ phần mềm. Theo lối tiếp cận này, chúng ta quan tâm chủ yếu tới những thông tin mà hệ thống sẽ lưu trữ. Chúng ta hỏi người dùng xem họ sẽ cần những thông tin nào, rồi chúng ta thiết kế ngân hàng dữ liệu để chứa những thông tin đó, cung cấp Forms để nhập thông tin và in báo cáo để trình bày các thông tin. Nói một cách khác, chúng ta tập trung vào thông tin và không mấy để ý đến những gì có thể xảy ra với những hệ thống đó và cách hoạt động (ứng xử) của hệ thống là ra sao. Đây là lối tiếp cận xoay quanh dữ liệu và đã được áp dụng để tạo nên hàng ngàn hệ thống trong suốt nhiều năm trời. Lối tiếp cận xoay quanh dữ liệu là phương pháp tốt cho việc thiết kế ngân hàng dữ liệu và nắm bắt thông tin, nhưng nếu áp dụng cho việc thiết kế ứng dụng lại có thể khiến phát sinh nhiều khó khăn. Một trong những thách thức lớn là yêu cầu đối với các hệ thống thường xuyên thay đổi. Một hệ thống xoay quanh dữ liệu có thể dể dàng xử lý việc thay đổi ngân hàng dữ liệu, nhưng lại khó thực thi những thay đổi trong nguyên tắc nghiệp vụ hay cách hoạt động của hệ thống. Phương pháp hướng đối tượng đã được phát triển để trả lời cho vấn đề đó. Với lối tiếp cận hướng đối tượng, tập trung vào cả hai mặt của vấn đề : thông tin và cách hoạt động. 3.2. Thiết kế xử lý Thiết kế phần mềm thường được xem như là một quy trình 2 bước: Thiết kế kiến trúc (cũng được xem như là thiết kế mức cao high- level design or top- level design) mô tả phầm mềm được tổ chức thành các thành phần như thế nào Thiết kế chi tiết mô tả hành động mong muốn của những thành phần Đầu ra của 2 quy trình này là tập mô hình và tài liệu ghi lại những những quyết định quan trọng đã được thực hiện cùng lời giải thích cho mỗi lý do. Bằng cách ghi lại các lý do đó công việc bảo trì dài hạn của phần mềm được nâng cao. 4. Thiết kế hệ thống hướng đối tượng 4.1. Một số khái niệm UML Khi thực hiện các dự án phần mềm, ứng dụng tôi có thói quen chia đôi thời gian thực hiện, một nửa dành cho việc tìm hiểu nghiệp vụ, phân tích tính năng và thiết kế database, một nửa thời gian còn lại dành cho việc code. Trong thời đại mở của các nền tảng kỹ thuật chúng ta hoàn toàn có thể áp dụng những công nghệ tốt nhất cho hiệu suất ứng dụng của mình, lúc này việc ứng dụng hoạt động ổn định, đúng nghiệp vụ, dễ dàng mở rộng theo yêu cầu thay đổi của tình hình thực tế lại là điều quan trọng hơn. Phân tích và thiết kế hướng đối tượng OOAD (Object Oriented Analysis and Design) và ngôn ngữ mô hình hóa UML (Unified Modeling Language) phổ biến và được đưa vào các trường đào tạo ngành CNTT tuy nhiên để áp dụng thực tế với sinh viên vẫn còn tương đối khó khăn. Trong bài này chúng ta sẽ tiếp cận bằng cách đơn giản những kiến thức về Phân tích và thiết kế hướng đối tượng và UML để cùng hiểu và áp dụng vào thực tế. 41 Khái niệm OOAD (Object Oriented Analysis and Design) Phân tích và thiết kế hướng đối tượng là một kỹ thuật tiếp cận phổ biến dùng để phân tích, thiết kế một ứng dụng, hệ thống. Nó dựa trên bộ các nguyên tắc chung, đó là một tập các hướng dẫn để giúp chúng ta tránh khỏi một thiết kế xấu. 5 nguyên tắc SOLID trong thiết kế hướng đối tượng: · Một lớp chỉ nên c...nhân, phép chia đúng. Nếu bạn nhận việc kiểm thử phần mềm Calculator, nhấn phím “+” và không có chuyện gì xảy ra, đó chính là một lỗi Quy tắc 2: Phần mềm thực hiện một số việc mà bản đặc tả yêu cầu nó không được thực hiện Ví dụ: Bản đặc tả phần mềm yêu cầu rằng, calculator sẽ không bao giờ bị đột ngột ngưng hoạt động, bị khóa lại hoặc bị đóng băng. Nếu bạn ấn liên tục lên các phím và nhận được thông điệp từ calculator là “not responding” (dừng quá trình hồi đáp với dữ liệu vào), đây là một lỗi theo quy tắc 2. Quy tắc 3: Phần mềm thực hiện một số chức năng mà bản đặc tả không đề cập tới Ví dụ: Lập trình viên tự ý thêm vào phép tính căn bậc 2, trong khi đặc tả của calulator chỉ yêu cầu các phép tính cộng, trừ, nhân, chia. Quy tắc 4: Phần mềm không thực hiện một số việc mà bản đặc tả không đề cập tới, nhưng là những việc nên làm Ví dụ: Bạn mong muốn rằng công việc sẽ được duy trì cho đến khi pin hoàn toàn hết, hoặc ít nhất bằng cách nào đó báo cho bạn biết Pin đã yếu. Những phép tính đúng đã không xảy ra khi pin yếu, và nó cũng không chỉ rõ điều gì sẽ xảy đến. Quy tắc số 4 tạo nên lỗi này. Quy tắc 5: Trong con mắt của người kiểm thử, phần mềm là khó hiểu, khó sử dụng, chậm đối với người sử dụng Trong trường hợp của calculator, có lẽ bạn đã tìm thấy những nút có kích thước quá nhỏ. Hoặc có thể sự sắp xếp của nút “=” đã làm cho nó khó sử dụng. Hoặc sự bố trí màu sắc làm cho nó rất khó nhìn... Tất cả những điều này đều là lỗi (bug) theo quy tắc 5. Vòng đời của lỗi? Vòng đời của lỗi là một hành trình mà mà lỗi đi qua trong suốt cuộc đời của nó. Nó thay đổi từ tổ chức này sang tổ chức khác, từ dự án này đến dự án khác và nó được điều chỉnh bởi quy trình kiểm thử phần mềm. Vòng đời của lỗi bao gồm các trạng thái dưới đây: New: Khi mà lần lỗi được log lên lần đầu tiên bời người kiểm thử Assigned: Khi lỗi đã được đăng lên và chỉ định cho lập trình viên nào đó Open: Khi lập trình viên đang sửa lỗi Fixed: Khi lập trình viên đã hoàn thành việc sửa lỗi 52 Retest: Người kiểm thử kiếm tra lại lỗi đã được sửa hay chưa, có phát sinh thêm lỗi mới nào không Reopened: Nếu lỗi vẫn còn, người kiểm thử sẽ trả lại cho lập trình viên. Lỗi phải đi lại một vòng đời như cũ. Deferred: Lỗi sẽ được sửa trong bản phát hành tiếp theo. Lý do có thể là độ ưu tiên của lỗi có thể là thấp, thiếu thời gian để phát hành hoặc lỗi có thể không có ảnh hưởng lớn đến phần mềm. Rejected: Nếu lập trình viên cho rằng không phải là lỗi, họ có thể chuyển sang trạng thái này Duplicate: Lỗi được đăng trùng với nhau Closed: Khi người kiểm thử đã thấy lỗi được sửa triệt để Not a bug/Enhancement: Một số thay đổi trong ứng dụng, không phải là lỗi 1.2. Kiểm thử và tiến trình kiểm thử Định nghĩa về kiểm thử và thuật ngữ liên quan Kiểm thử phần mềm là một cuộc kiểm tra được tiến hành để cung cấp cho các bên liên quan thông tin về chất lượng của sản phẩm hoặc dịch vụ được kiểm thử. Kiểm thử có thể cung cấp cho doanh nghiệp một quan điểm, một cách nhìn độc lập về phần mềm để từ đó cho phép đánh giá và thấu hiểu được những rủi ro trong quá trình triển khai phần mềm. Trong kỹ thuật kiểm thử không chỉ giới hạn ở việc thực hiện một chương trình hoặc ứng dụng với mục đích đi tìm các lỗi phần mềm (bao gồm các lỗi và các thiếu sót) mà còn là một quá trình phê chuẩn và xác minh một chương trình máy tính / ứng dụng / sản phẩm nhằm: • Đáp ứng được mọi yêu cầu hướng dẫn khi thiết kế và phát triển phần mềm. • Thực hiện công việc đúng như kỳ vọng. • Có thể triển khai được với những đặc tính tương tự. • Và đáp ứng được mọi nhu cầu của các bên liên quan. Tùy thuộc vào từng phương pháp, việc kiểm thử có thể được thực hiện bất cứ lúc nào trong quá trình phát triển phần mềm. Lỗi và chịu lỗi Tiêu chí lựa chọn kiểm thử/Kiểm tra mức độ đầy đủ tiêu chí Tiêu chí lựa chọn thử nghiệm có nghĩa là lựa chọn trường hợp kiểm thử hoặc xác định một tập các trường hợp kiểm thử là đủ cho một mục đích cụ thể. Hiệu quả kiểm thử/Mục tiêu kiểm thử Hiệu quả kiểm thử được xác định bằng cách phân tích một tập hợp các chương trình thực thi. Lựa chọn kiểm thử được thực hiện có thể được hướng dẫn bởi các mục tiêu khác nhau. Kiểm thử phát hiện khiếm khuyết Phát hiện lỗi hoặc những khiếm khuyết của phần mềm để thấy được ứng xử của nó có chính xác hoặc phù hợp với tài liệu đặc tả của nó hay không. Về mặt lý thuyết, chúng ta phải kiểm thử hệ thống một cách cặn kẽ thì mới khẳng định được chương trình không còn khiếm khuyết. Tuy nhiên, trong thực tế không thể kiểm thử một cách cặn kẽ được. Các vấn đề về Oracle Oracle là bất kỳ người hoặc máy móc dùng để quyết định xem liệu một chương trình có thực hiện một cách chính xác trong một thử nghiệm nhất định và phù hợp kết quả là đạt hoặc thất bại (các nguyên tắc hay cơ chế phát hiện vấn đề). Kiểm thử không thể xác định hoàn toàn được tất cả các lỗi bên trong phần mềm. Thay 53 vào đó, nó so sánh trạng thái và hành vi của sản phẩm với các oracle. Các oracle này có thể bao gồm (nhưng không giới hạn ở) các đặc tả phần mềm, hợp đồng, sản phẩm tương đương, các phiên bản trước của cùng một sản phẩm, phù hợp với mục đích dự kiến nhằm đáp ứng sự kỳ vọng của người dùng, khách hàng, quy định của pháp luật hiện hành và các tiêu chuẩn liên quan khác. Vấn đề về đường dẫn không khả thi Đường dẫn không khả thi là các đường dẫn luồng điều khiển không thể được thực thi bởi bất kỳ dữ liệu đầu vào. Khả năng kiểm thử Khả năng kiểm thử là mức độ mà một thành phần phần mềm (hệ thống phần mềm, module, tài liệu thiết kế) hỗ trợ kiểm thử trong một bối cảnh kiểm thử nhất định. Nếu khả năng kiểm thử của thành phần phần mềm cao, thì việc tìm kiếm lỗi trong hệ thống (nếu có) bằng việc kiểm thử được dễ dàng hơn. Mối quan hệ của kiểm thử với các hoạt động khác Kiểm thử vs kỹ thuật quản lý chất lượng phần mềm tĩnh Kiểm thử vs Bằng chứng về tính đúng đắn và xác minh hình thức Kiểm thử vs Gỡ lỗi Kiểm thử vs Xây dựng chương trình 1.3 Các mức kiểm thử Dựa trên trực giác và kinh nghiệm của kỹ sư phần mềm Có lẽ kỹ thuật được thực hiện nhiều nhất là kiểm thử tùy biến: các kiểm thử có được dựa trên kỹ năng, trực quan và kinh nghiệm của kỹ sư phần mềm với cá chương trình quen thuộc. Kiểm thử tùy biến có thể hữu ích cho việc định danh các trường hợp kiểm thử mà không dễ thực hiện bằng các kỹ thuật bình thường. Kiểm thử theo kiểu khám phá được định nghĩa là tiến hành đồng thời việc học tập, thiết kế và thực hiện kiểm thử, nó không được thực hiện theo kế hoạch kiểm thử đã được lên trước và linh động về việc thiết kế, thực hiện và sửa đổi. Hiệu quả của kiểm thử khám phá phụ thuộc và kinh nghiệm của kỹ sư phần mềm, điều này có được từ nhiều nguồn như quan sán hành vi của sản phẩm trong quá trình kiểm thử, sự quen thuộc với các ứng dụng, môi trường, quá trình lỗi, các dạng lôi có thể có, nguy cơ khi tích hợp với các sản phẩm riêng biệt. Kỹ thuật dựa trên miền đầu vào Phân vùng tương đương liên quan đến việc phân chia miền đầu vào thành các vùng dựa trên tiêu chuẩn hoặc quan hệ. Tiêu chuẩn hoặc quan hệ này có thể là những kết quả tính toán khác nhau, quan hệ dựa trên luồng điều khiển hoặc luồng dữ liệu, hoặc một sự phân biệt được tạo ra giữa các đầu vào hợp được chấp nhận và đầu vào không hợp lệ sẽ bị từ chối và đưa ra lỗi. Các trường hợp kiểm thử có được bằng việc kết hợp các giá trị tiêu biểu cho mỗi cặp của một tập hợp biến đầu vào thay vì xét đến toàn bộ các kết hợp có thế có. Kiểm thử theo cặp thuộc về kiểm thử tổ hợp, nhìn chung bao gồm mức tổ hợp cao hơn so với cặp: những kỹ thuật này được xem như t-wise, cái mà toàn bộ tổ hợp đầu vào t được xem xét. Các trường hợp kiểm thử được chọn ra sẽ nằm trên hoặc gần với điên của miền đầu vào, nơi tỉ lệ lỗi thường tập chung cao nhất. Trường hợp ngoại lệ của kỹ thuật này là kiểm thử sự bền vững, nơi mà trường hợp kiểm thử được chọn bên ngoài miền biến đầu vào để kiểm thử sự bền vững của sản phầm trong việc xử lý đầu vào lỗi. 54 Các kiểm thử được thực hiện đơn thuẩn một cách ngẫu nhiên. Dạng kiểm thử này đặt dưới đầu của miền đầu vào bởi vì miền đầu vào phải được biến để để có thể lấy ra được những điểm ngẫu nhiên. Kiểm thử ngẫu nhiên cung cấp một tiếp cận đơn giản để kiểm thử tự động, gần đây các dạng nâng cao của kiểm thử ngẫu nhiên được đưa ra, mẫu đầu vào ngẫu nhiên được hướng bởi tiêu chuẩn lựa chọn đầu vào khác. Kiểm thửu Fuzz hay Fuzzing là dạng đặc biệt của kiểm thử ngẫu nhiên,tập chung vào việc phá vỡ phần mềm, nó chủ yếu được dùng để kiểm thử an ninh của phần mềm. Kỹ thuật dựa trên mã nguồn Tiêu chuẩn phủ dựa trên luồng điều khiển được tập chung vào việc phủ toàn bộ các câu lệnh, khối lệnh hoặc kết hợp đặc biệt của các câu lệnh trong chương trình. Điểm mạnh nhất của tiêu chuẩn này là kiểm thử đường đi, cái mà tập chung vào để thực thi toàn bộ đường đi lường điều khiển từ khi vào đến khi kết thúc trong biểu đồ luồng điều khiển của chương trình. Vì kiểm thử vét kiệt đường đi là không khả thi do vòng lặp, tiêu chuẩn ít chính xác tập chung vào đọ phủ của đường đi các mà giới hạn các bước lặp như phủ câu lệnh, phủ nhánh và kiểm thử quyết định. Sự đầy đủ của các kiểm thử như thế được đo đạc theo phần trăm, ví dụ, khi tất cả các nhánh được thự thi ít nhất một lần khi kiểm thử thì độ phủ nhánh là 100%. Trong kiểm thử dựa trên luồng dữ liệu, biểu đồ luồng điều khiển được diễn giải với thông tin về việc bằng cách nào các biến chương trình được định nghĩa, dử dụng và kết thúc. Tiêu chuẩn mạnh nhất yêu cầu từ định nghĩa của biến đến việc sử dụng định nghĩa đó được thực thi. Để giảm số đường đi yêu cầu, những chiến lược yếu hơn như định nghĩa tất cả và sử dụng tất cả được dùng. Mặc dù bản thân không phải là một kỹ thuật, cấu trúc điều khiển của một chương trình có thể được hình ảnh hoá để biểu diễn việc sử dụng một biểu đồ như kỹ thuật dựa trên mã nguồn. Một biểu đồ là đồ thị có hướng, các nút và cung biểu diễn cho các yếu tố của chương trình. Ví dụ, các nút có thể biểu diễn các lệnh hoặc tần xuất không bị can thiệp của lệnh và cung có thể biểu diễn sử trao đổi giữa các nút. Kỹ thuật dựa trên lỗi Trong việc dự đoán lỗi, các trường hợp kiểm thử được thiết kế đặc biệt bởi kỹ sư phần mềm người mà cố gắng dự đoán trước các lỗi có thể xảy ra trong chương trình cho trước. Một nguồn thông tin tốt là lịch sử lỗi được tìm ra trong những dự án có trước cũng như kỹ năng của kỹ sư phần mềm. Một đột biến là một phiên bản chỉnh sửa nhẹ của chương trình đang kiểm thử, với một sử thay đổi nhẹ để khác biệt với chương trình cũ. Mỗi lần kiểm thử là kiểm thử phiên bản gốc và toàn bộ các đột biến: nếu trường hợp kiểm thử thành công trong việc định danh sự khác biệt giữa chương trình và đột biến thì đột biến sẽ bị tiêu diệt. Nói cách khác, khi một đột biến được kiểm thử mà trả kết quả khác so với bản gốc thì đột biến bị tiêu diệt và xem như bản gốc đạt tiêu chuẩn. Khi bản đột biến mà cho kết quả giống bản gốc thì xem như kiểm thửu thất bại. Hiệu của của kỹ thuật này được đánh giá bằng số lượng lớn của các đột biến bị tiêu diệt. Các đột biến thường được tạo ra một cách tự động và kiểm thử thực hiện theo một cách có hệ thống. Kỹ thuật dựa trên việc sử dụng 55 Trong việc kiểm thử sự đánh giá độ tin cậy, mội trường kiểm thử được tạo ra gần với môi trường vận hành của phần mềm hoặc gọi là hồ sơ vận hành. Mục tiêu là để suy ra từ các kết quả đã được theo dõi độ tin cậy tương lai của phần mềm khi được sử dụng thật. để làm điều này, đầu vào được gán các xác suất hoặc hồ sơ theo tần suất xảy ra trong thực tế. Hồ sơ vận hành so thể được dùng trong kiểm thử hệ thống để hướng dẫn bắt nguồn của các trường hợp kiểm thử sẽ đánh giá sự tin cậy và thử nghiệm liên quan đến việc sử dụng và các chức năng khác nhau giống với những gì xảy ra trong môi trường kiểm thử vận hành. Các nguyên tắc sử dụng có thể cung cấp hướng dẫn cho việc tìm ra vấn đề trong thiết kế giao diện. Nguồn thông tin cho vấn đề này có thể được lấy qua các nguồn như phỏng vấn và làm khảo sát người dùng. Kỹ thuật dựa trên mô hình Những bảng quyết định biểu diễn các mối quan hệ logic giữa các điều kiện và hành động. Các trường hợp kiểm thử có được một cách hệ thống bằng việc xem xét mọi tổ hợp của điều kiện và các hành động phản ứng. Một kỹ thuật liên quan là đồ thị nguyên nhân - ảnh hưởng. Bằng việc mô hình hóa một chương trình như một máy trạng thái hữu hạn, việc kiểm thử được lựa chọn để bao phủ các trạng thái và sự chuyển tiếp. Trạng thái hóa cả chi tiết kỹ thuật trong ngôn ngữ hình thức cho phép sự dẫn xuất tự động các trường hợp kiểm thử chức năng và cùng lúc cung cấp một dự đoán cho việc kiểm tra kết quả kiểm thử. TTCN3 là một ngôn ngữ được phát triển để viết ra các trường hợp kiểm thử. Định nghĩa được hiểu với những yêu cầu riêng biệt của kiểm thử các hệ thống truyền thông, vì thế nó đặc biệt thích hợp cho kiểm thử các giao thức truyền thông phức tạp. Mô hình luồng công việc chỉ ra tần xuất của các hoạt động được thực hiện bởi con người hay ứng dụng phần mềm, thường được biểu diễn thông qua các định nghiwax hình ảnh. Mỗi tần suất của hành động cấu thành một luồng công việc. Kỹ thuật dựa trên tính chất của phần mềm Các kỹ thuật bên trên áp dụng cho toàn bộ các loại phần mềm. các kỹ thuật phụ cho kiểm thử dựa trên tính chấn của phần mềm như: Phần mềm hướng đối tượng Phần mềm dựa trên bộ phận Phần mềm nền web Các chương trình tương tranh Phần mềm dựa trên giao thức Hệ thống thời gian thực Hệ thống an toàn nguy cấp Phần mềm hướng dịch vụ Phần mềm mã nguồn mở Phần mềm nhúng Chọn và kết hợp các kỹ thuật Các kỹ thuật kiểm thử dựa trên mô hình và mã nguồn thường tương phản như kiểm thử chức năng và cấu trúc. Hai cách tiếp cận lựa chọn kiểm thử này không được xem như thay thế cho nhau mà được xem là bổ sung cho nhau; trong thực tế, chúng sử dụng các nguồn thông tin khác nhau và đã chỉ ra các loại vấn đề tiêu biểu khác nhau. Chúng có thể được dùng kết hợp và phụ thuộc vào xem xét đầu tư. 56 Các trường hợp kiểm thử được chọn theo cách tất định, theo một trong số các kỹ thuật hoặc thực hiện ngẫu nhiên từ sự phân phối đầu vào như trong kiểm thử độ tin cậy. Một vài so sánh theo kiểu phân tích và kinh nghiệm được chọn để phân tích các điều kiện mà tạo cách tiếp cận có hiệu quả hơn. 1.4 Một số thuật ngữ Các phép đo chương trình hỗ trợ lên kế hoạc và thiết kế kiểm thử Các phép đó dựa trên kích cỡ của phần mềm (ví dụ: các dòng mã nguồn hoặc kích thước chức năng) hoặc cấu trúc phần mềm có thể được dùng để hướng dẫn kiểm thử. Các phép đo cấu trúc bao gồm các phép đo mà quyết định tần suất của mô đun này gọi thực hiện mô đun khác. Các loại lỗi, phân loại và thống kê Văn học kiểm thử đa dạng trong phân loại và nguyên tắc phân loại lỗi. Để tạo ra kiêm thử hiệu quả hơn thì quan trọng là biết loại lỗi nào có thể được phát hiện trong phần mềm đang kiểm thử và tần xuất tương đối những lỗi đó tồn tại trong quá khứ. Thông tin này có thể hữu ích trong việc dự đoán chất lượng cũng như trong việc cải tiến quá trình. Mật độ lỗi Một chương trình đang kiểm thử có thể được đánh giá bằng việc tính toán các lỗi đã được tìm ra như tỉ lệ giữa số lỗi được tìm thấy và độ lớn cửa chương trình. Đánh giá độ tin cậy Một ước lượng thống kê của độ tin cậy phần mềm có thể được dùng để đánh giá một sản phẩm phần mềm và quết định kiểm thử có thể dừng lại hay không bằng việc quan sát độ tin cậy được tạo ra. Những mô hình phát triển độ tin cậy Những mô hình phát triển độ tin cậy cung cấp dự đoán dộ tin cậy dựa trên lỗi. Chúng giả định rằng các lỗi gây ra các thất bại được quan sát đều được sửa, độ tin cậy của sản phầm đữa ra một xu thế tăng dần. Rất nhiều mô hình kiểu này được đưa ra. Đáng chú ý, những mô hình này được chi ra là 2 loại là mô hình đếm lỗi và mô hình thời gian giữa các lỗi. Các phép đo phủ Một vài tiêu chuẩn kiểm thử yêu cầu rằng các trường hợp kiểm thử thực hiện một tập yếu tố được định danh trong chương trình hoặc trong chi tiết kỹ thuật một các hệ thống. Để đánh giá độ chi tiết của các kiểm thử được thực hiện, các kỹ sư phần mềm cso thể theo dõi các yếu tố được bao phủ để họ có thể đo đạc tỉ lệ giữa yếu tố được phủ và tổng số một các linh động. Ví dụ, có thể đo tỉ lệ phần trăm của các nhánh được phủ trong biểu đồ dòng chảy chương trình hoặc phần trăm yêu cầu chức năng được thực hiện và danh sách chức năng trong tài liệu chi tiết kỹ thuật. Các tiêu chí phù hợp dứa trên mã nguồn yêu cầu sự đo đạc thích hợp của chương trình đang kiểm thử. Gieo lỗi Trong việc gieo lỗi, vài lỗi được đưa nhân tạo vào chương trình trước khi kiểm thử. Khi kiểm thử được tiến hành, và trong số này sẽ được bộc lộ cũng như và lỗi có sẵn. Theo lý thuyết, phụ thuộc vào việc cái nào và bao nhiêu lỗi nhân tạo được tìm ra, hiệu quả kiểm thử và số lỗi thực có thể được đánh giá. Trong thực tế, các nhà thống kê đặt ra câu hỏi thử phân phối và biểu diễn của các lỗi được gieo trước đó quan hệ vơi lỗi thật và một cỡ bé mẫu thử lên bất kỳ phéo ngoại suy nào được 57 dựa trên. Một số khác tranh cãi rằng kỹ thuật này nên dùng thận trọng vì việc chèn lỗi vào phần mềm liên quan đến mạo hiểm rõ rằng rằng có thể quên các lỗi đó trong chương trình. Điểm đột biến Trong kiểm thử đột biến, tỉ lệ các đột biến bị tiêu diệt với tổng số đột biến có thể là phép đo cho sự hiệu của của tập kiểm thử được thực hiện. Sự so sánh và hiệu quả tương đối của các kỹ thuật khác nhau Và nghiên cứu được tiến hành đê so sánh hiệu quả tương đối của việc sử dụng các kỹ thuật khác nhau. Quan trọng là để được chính xác như đối với thuộc tính dựa vào đó các kỹ thuật đang được đánh giá. Cách diễn dải có thể bao gồm số các kiểm thử cần để tìm ra lỗi đầu tiên, tỉ lệ của số lỗi được tìm ra thông qua kiểm thử và toàn bộ số lỗi được tìm ra trong và sau khi kiểm thử, và cải thiện độ tin cậy được bao nhiêu. Các so sánh phân tích và thực nghiệm giữa các kỹ thuật khác nhau được tiến hành theo từng ý niệm về hiệu quả quy định ở trên 2. Các cấp độ kiểm thử Kiểm thử phần mềm thường được thực hiện ở các cấp độ khác nhau trong suốt quá trình phát triển và bảo trì. Mức có thể được phân biệt dựa trên các đối tượng thử nghiệm, được gọi là các target, hoặc về mục đích, được gọi là các objective (từ cấp thử nghiệm). Mục tiêu của kiểm thử (Target of the Test) Mục tiêu của thử nghiệm có thể khác nhau: một mô-đun duy nhất, một nhóm các mô-đun như (liên quan theo mục đích, sử dụng, hành vi, hoặc cơ cấu), hay toàn hệ thống. Ba giai đoạn thử nghiệm có thể được phân biệt: đơn vị, tích hợp và hệ thống. 2.1. Kiểm thử đơn vị Unit testing đề cập đến các kiểm thử để chứng thực (xác minh - verify) chức năng của một phần riêng biệt của code, thường ở mức hàm (function level). Trong một môi trường hướng đối tượng (object-oriented environment), kiểm thử đơn vị thường được sử dụng ở mức lớp (class) và kiểm thử các đơn vị nhỏ nhất bao gồm các hàm constructor và destructor. Loại kiểm thử này thường được viết bởi các DEV như công việc của họ trong việc code (loại test white-box), để bảo đảm rằng từng hàm riêng biệt hoạt động đúng theo mong muốn. Một hàm có thể có nhiều kiểm thử, để bắt được các trường hợp hoặc các nhánh trong code. Unit testing một mình không thể bảo đảm chức năng của một bộ phận của phần mềm mà là sử dụng để bảo đảm rằng các khối kiến trúc của phần mềm làm việc độc lập với nhau. Unit testing (kiểm thử đơn vị) cũng được gọi là component testing (kiểm thử thành phần). 2.2. Kiểm thử tích hợp Integration testing là một loại kiểm thử phần mềm mà tìm kiếm để kiểm tra các giao diện giữa các thành phần dựa vào thiết kế của phần mềm. Các thành phần phần mềm có thể được tích hợp lại với nhau theo cách lặp đi lặp lại (từng phần nhỏ ghép lại với nhau, rồi ghép tiếp phần nhỏ khác vào nữa, hành động này lặp lại cho đến khi kết hợp toàn bộ phần mềm) hoặc tất cả các thành phần cùng tích hợp một lần (gọi là “big bang”). Thông thường trước đây được xem là một cách làm 58 tốt hơn từ khi nó cho phép các vấn đề về giao diện được xác định vị trí nhanh hơn và cố định. Integration testing làm việc để tìm ra lỗi (defect) trong các giao diện và giao tiếp giữa các thành phần (mô-đun). Các nhóm thành phần phần mềm đã được kiểm thử lớn dần từng bước tương ứng với các yếu tố của thiết kế kiến trúc đã được tích hợp và kiểm thử cho đến khi phần mềm hoạt động như một hệ thống. 2.3. Kiểm thử hệ thống System testing kiểm thử một hệ thống đã được tích hợp hoàn chỉnh để xác minh rằng nó đáp ứng được yêu cầu. Kiểm thử tích hợp hệ thống chứng thực rằng hệ thống đã được tích hợp với các hệ thống bên ngoài hoặc hệ thống thứ ba đã được xác định trong các yêu cầu hệ thống. Mục đích của kiểm thử Kiểm thử được tiến hành trong bối cảnh mục tiêu cụ thể, trong đó được ghi nhận nhiều hơn hoặc ít hơn một cách rõ ràng và có độ chính xác khác nhau. Trong đó nêu rõ mục đích của kiểm thử một cách chính xác, hỗ trợ về mặt định lượng đo lường và kiểm soát trong quá trình kiểm thử. Kiểm thử có thể được dùng để xác minh các tính chất khác nhau. Trường hợp kiểm thử có thể được thiết kế để kiểm tra các thông số kỹ thuật chức năng được thực hiện một cách chính xác, hiệu suất, độ tin cậy, khả dụng... Nghiệm thu/Năng lực kiểm thử Nghiệm thu/Năng lực kiểm thử xác định một hệ thống đáp ứng tiêu chuẩn nghiệm thu của nó, thường là bằng cách kiểm tra các hành vi hệ thống mong muốn đối với các yêu cầu của khách hàng. 2.4. Kiểm thử chấp nhận Nhiệm vụ chính của phần này là đánh giá như thế nào là dễ dàng cho người dùng cuối để tìm hiểu và sử dụng phần mềm. Nói chung, nó có thể liên quan đến việc thử nghiệm các chức năng phần mềm hỗ trợ việc sử dụng, tài liệu hướng dẫn nhằm hỗ trợ người sử dụng, và khả năng của hệ thống để phục hồi từ lỗi người sử dụng 3. Các kỹ thuật kiểm thử. 3.1. Kiểm thử hộp đen - Black-box Testing Black Box Testing là gì? Kiểm tra hộp đen (Black box testing) là một phương pháp kiểm thử phần mềm mà việc kiểm tra các chức năng của một ứng dụng không cần quan tâm vào cấu trúc nội bộ hoặc hoạt động của nó. Phương pháp thử nghiệm Black Box Testing Dựa vào chức năng Kiểm thử hộp đen (Black box testing) có thể được áp dụng hầu như đến mọi cấp độ của kiểm thử phần mềm: · Kiểm thử đơn vị (Unit testing) · Kiểm thử tích hợp (Integration testing) · Kiểm thử hệ thống (System testing) · Kiểm thử chấp nhận (Acceptance testing). Tuy nhiên, Black box test được sử dụng thích hợp nhất trong kiểm thử hệ thống (System test) và Kiểm thử chấp nhận (Acceptance testing) 59 Ưu điểm Black Box Testing · Các Tester được thực hiện từ quan điểm của người dùng và sẽ giúp đỡ trong việc sáng tỏ sự chênh lệch về thông số kỹ thuật. · Các Tester theo phương pháp black box không có “mối ràng buộc” nào với code, và nhận thức của một tester rất đơn giản: một source code có nhiều lỗi. Sử dụng nguyên tắc, “Hỏi và bạn sẽ nhận” các tester black box tìm được nhiều bug ở nơi mà các developer không tìm thấy. · Tester không cần phải biết ngôn ngữ lập trình hoặc làm thế nào các phần mềm đã được thực hiện. · Thiết kế kịch bản kiểm thử khá nhanh, ngay khi mà các yêu cầu chức năng được xác định. Nhược điểm Black Box Testing Người ta nói kiểm thử hộp đen giống như là đi trong bóng tối mà không có bóng đèn vậy “, bởi vì kiểm thử viên không biết các phần mềm được kiểm tra thực sự được xây dựng như thế nào. Đây là lý do mà một kiểm thử viên viết rất nhiều test case để kiểm tra một thứ gì đó mà đáng lẽ ra chỉ cần 1 ca kiểm thử là đủ, và/hoặc một số phần của phần mềm không được kiểm thử chút nào. Vòng đời phát triển của kiểm thử hộp đen. Kiểm thử hộp đen có chu kỳ sống riêng của nó được gọi là vòng đời kiểm thử phần mềm( STLC) và nó liên quan đến mọi giai đoạn của Vòng đời phát triển phần mềm. · Requirement – Đây là giai đoạn ban đầu của SDLC và trong giai đoạn này các yêu cầu được thu thập. Kiểm thử phần mềm cũng tham gia vào giai đoạn này. · Test Planning & Analysis – Các loại thử nghiệm áp dụng cho dự án được xác định. Một kế hoạch thử nghiệm được tạo ra để xác định các rủi ro có thể xảy ra của dự án và giảm thiểu sự rủi ro của chúng. · Design – Trong giai đoạn này các trường hợp / tập lệnh thử nghiệm được tạo trên cơ sở các tài liệu yêu cầu phần mềm · Test Execution – Trong giai đoạn này chúng ta thực hiện các trường hợp thử nghiệm đã chuẩn bị. Phương pháp kiểm thử hộp đen Đoán lỗi: Là một kỹ năng quan trọng của tester, thậm chí có thể gọi là nghệ thuật. Một kiệt tác của trực giác. Phương pháp này đặc biệt dựa vào kinh nghiệm và kiến thức của tester. Nhiều tester cố gắng đoán xem phần nào của hệ thống mà có khả năng ẩn chứa lỗi. Với phương pháp này, họ không cần một công cụ hay một kịch bản kiểm thử nào khi bắt đầu vào việc. Kiểm thử dựa vào đồ thị nguyên nhân – kết quả (Cause Effect Graphing): là một kỹ thuật thiết kế kiểm thử phần mềm liên quan đến việc xác định các trường hợp (điều kiện đầu vào) và các hiệu ứng (điều kiện đầu ra). Vì các hệ thống hiện nay đều được phát triển trên nền tảng OOP, do đó, chúng ta có thể có được một đồ thị các đối tượng mà hệ thống định nghĩa và kết nối. Từ đồ thị này, chúng ta dễ dàng biết các mối quan hệ của những đối tượng mà hệ thống xử lý, từ đó sẽ cho chúng ta các kịch bản kiểm thử phù hợp. Phân vùng tương đương (Equivalence Class) : 60 Là một kỹ thuật kiểm thử phần mềm có liên quan đến phân chia các giá trị đầu vào thành các phân vùng hợp lệ và không hợp lệ, sau đó chúng ta sẽ viết ra các kịch bản kiểm thử cho từng phần, chọn giá trị đại diện từ mỗi phân vùng làm dữ liệu thử nghiệm. · Phân vùng tương đương: là kỹ thuật thực hiện test theo từng class đồng giá trị (tập hợp điều kiện cùng một thao tác). · Tập hợp giá trị input có cùng một kết quả xử lý, tập hợp thời gian có cùng một kết quả xử lý, tập hợp kết quả export được xử lý cùng một giá trị nhập. · Mục đích : Giảm đáng kể số lượng test case cần phải thiết kế vì với mỗi lớp tương đương ta chỉ cần test trên các phần tử đại diện. · Chọn tối thiểu một giá trị đại diện từ các class đồng giá trị để tiến hành test. Nếu có lỗi xảy ra thì các giá trị khác trong class đồng giá trị cũng sẽ có lỗi giống nhau. Phân tích giá trị biên (Boundary Value Analysis): Là một kỹ thuật kiểm thử phần mềm có liên quan đến việc xác định biên (ranh giới) của điều kiện mô tả cho các giá trị đầu vào và chọn giá trị ở biên và bên cạnh giá trị biên làm dữ liệu kiểm thử. Phương pháp phân tích giá trị biên sẽ đưa ra các giá trị đặc biệt, bao gồm loại dữ liệu, giá trị lỗi, bên trong, bên ngoài biên giá trị, lớn nhất và nhỏ nhất. Những kỹ sư nhiều kinh nghiệm chắc chắn đã từng gặp phải các lỗi của hệ thống ngay tại giá trị biên. Đó là lý do tại sao phân tích giá trị biên lại quan trọng khi kiểm thử hệ thống. · Test giá trị biên được thực hiện theo trình tự dưới đây: · Tìm ra đường biên · Quyết định giá trị biên · Quyết định giá trị để test · Giá trị biên. · Dưới giá trị biên. (Nếu là class đồng giá trị) · Trên 1 giá trị biên. (Nếu là class đồng giá trị) Sử dụng bảng quyết định (Decision Tables) · Là dùng bảng để hiển thị danh sách các thao tác phần mềm được quyết định trên các điều kiện khác nhau. · Decision table testing chú trọng vào nhiều điều kiện để thực hiện test. 3.2 Kiểm thử hộp trắng - White-box Testing White Box Testing là gì? Kiểm thử hộp trắng (White Box Testing) là một kỹ thuật xác minh giúp các Tester có thể sử dụng để kiểm tra mã code của họ hoạt động như dự kiến. Có 2 hoạt động kiểm thử hộp trắng: · Kiểm thử luồng điều khiển · Kiểm thử dòng dữ liệu Các kỹ thuật White Box Testing phổ biến Để thực hiện được kiểm thử hộp trắng, ta cần tuân thủ các bước cơ bản sau: · Hiểu được mã nguồn: Đây là việc cần thiết cần làm đầu tiên, vì kiểm thử hộp trắng liên quan đến kiểm tra các hoạt động bên trong nên bắt buộc phải hiểu được mã nguồn mà ta cần kiểm tra. Ngoài ra, ta cần phải thực hiện chặt chẽ vấn đề mã hóa an toàn vì bảo mật là cốt lỗi của việc kiểm thử này. 61 · Tạo và thực hiện các trường hợp kiểm thử: Việc viết thêm các đoạn mã để kiểm tra đoạn mã nguồn của ứng dụng sẽ là việc tiếp theo cần làm. Cần phải phát triển các thử nghiệm nhỏ cho từng quy trình hoặc cho từng chuỗi quy trình trong ứng dụng. Một ví dụ đơn giản với đoạn mã như sau: Printme (int a, int b) { ------------ Printme is a function int result = a+ b; If (result> 0) Print ("Positive", result) Else Print ("Negative", result) } Mục tiêu đặt ra là xác định tất cả các nhánh, các vòng lặp và câu lệnh trong đoạn mã trên. Và các trường hợp thử nghiệm của White Box Testing sẽ là A = 1, B = 1 A = -1, B = -3 Các trường hợp thử nghiệm trên sẽ bao phủ được các điều kiện, các nhánh cũng như các lệnh trong đoạn mã. Các loại kiểm thử hộp trắng · Unit testing: đây là phương pháp kiểm thử đầu tiên được thực hiện để kiểm tra một ứng dụng. Phương pháp này khá quan trọng nên ta sẽ bàn về nó ngay sau khi đọc xong phương pháp kiểm thử Black box testing. · Testing for Memory Leaks (kiểm tra rò rỉ bộ nhớ): Rò rỉ bộ nhớ là nguyên nhân hàng đầu khiến cho việc chạy ứng dụng trở nên chậm chạp hơn. Và khi có hiện tượng như trên thì cần phải nghĩ ngay đến trường hợp này. Ngoài ra cũng có một số phương pháp khác như: White Box Penetration Testing và White Box Mutation Testing Ưu điểm của White Box Testing: · Tối ưu hóa mã nguồn bằng cách tìm ra các lỗi ẩn. · Dễ dàng thực hiện tự động nhưng cũng kỹ lưỡng hơn · Và việc kiểm tra có thể bắt đầu sớm ngay cả khi GUI không khả dụng. Nhược điểm của White Box Testing: · Thực hiện khá phức tạp và tốn kém chi phí. · Đòi hỏi người kiểm thử phải thực sự chuyên nghiệp và hiểu biết về lập trình. · Tốn rất nhiều thời gian CÂU HỎI VÀ BÀI TẬP 1. Trình bày một số khái niệm cơ bản về kiểm thử phần mềm.? 2. Trình bày các cấp độ kiểm thử phần mềm? 3. Trình bày các kỹ thuật kiểm thử phần mềm.? 62 TÀI LIỆU THAM KHẢO [1]. Thạc Bình Cường, Nhập môn công nghệ phần mềm , NXB Giáo dục, 2008. [2]. Trần Đình Quế, Nhập môn công nghệ phần mềm, Đại học Đà Nẵng, Năm 2007. [3]. Giáo trình nhập môn UML, Huỳnh Văn Đức, Đoàn Thiện Ngân, NXB Lao động Xã hội,2003. [4]. Nguồn Internet.