(LUẬN VĂN THẠC SĨ) Nghiên cứu triển khai dịch vụ VPN,MPLS

Giới thiệu

Giới thiệu nhiệm vụ chính của đề tài

Kiểm thử phần mềm là một bước quan trọng trong quy trình phát triển, giúp phát hiện lỗi và ngăn ngừa sự thất bại của hệ thống Để đảm bảo chất lượng sản phẩm, việc kiểm thử đòi hỏi nguồn lực đáng kể và bao gồm các pha như kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử hệ thống và kiểm thử chấp nhận.

Quy trình kiểm thử được xây dựng nhằm đạt các mục tiêu chính như sau:

 Xem xét các yêu cầu đưa ra bởi khách hàng, đối chiếu với sản phẩm phần mềm được lập trình bởi lập trình viên

 Phát hiện các sai sót hoặc lỗi trong phần mềm mà ở đó hành vi phần mềm là không đúng, hoặc không tuân theo các đặc tả của nó

Phương pháp hướng đối tượng (Object-Oriented) đã chứng minh tính ưu việt trong phát triển phần mềm nhờ vào tính đóng gói, trừu tượng hóa và khả năng sử dụng lại, từ đó nâng cao chất lượng sản phẩm Theo Paul Allen, hiện nay hơn 70% hệ thống phần mềm mới được phát triển dựa trên cấu phần, thường viết bằng các ngôn ngữ khác nhau và chạy trên nhiều môi trường khác nhau Sự phân tán này, cùng với việc các nhà phát triển không được cung cấp mã nguồn, gây ra nhiều khó khăn trong việc kiểm thử hệ thống phần mềm Để cải thiện tính mềm dẻo trong việc nhận diện các chức năng và đặc điểm của phần mềm, việc sử dụng ngôn ngữ mô hình hóa chuẩn UML là cần thiết.

Ngôn ngữ mô hình hóa thống nhất (UML) là chuẩn công nghiệp cho phân tích và thiết kế hệ thống hướng đối tượng, cung cấp ký pháp biểu đồ thể hiện thông tin thiết kế từ nhiều góc độ khác nhau Gần đây, nhiều nghiên cứu đã sử dụng UML như nguồn thông tin đầu vào cho kiểm thử phần mềm, trong đó biểu đồ trạng thái mô tả hành vi bên trong của các đối tượng, biểu đồ tương tác hỗ trợ kiểm thử tương tác giữa các lớp, và biểu đồ hoạt động thể hiện mối quan hệ giữa các thành phần trong cấu phần.

Phương pháp phát triển phần mềm theo cấu phần đã chứng minh hiệu quả trong việc giảm chi phí dự án, đồng thời tăng cường khả năng sử dụng và bảo trì phần mềm So với công nghệ truyền thống, phương pháp này chú trọng vào việc tái sử dụng các cấu phần, giúp rút ngắn vòng đời phát triển và nâng cao chất lượng sản phẩm Nhiều nghiên cứu lý thuyết và công cụ hỗ trợ đã được phát triển để tối ưu hóa quy trình này Luận văn này sẽ khảo sát các vấn đề cơ bản và kỹ thuật liên quan đến phát triển phần mềm theo cấu phần, đặc biệt tập trung vào kỹ thuật kiểm thử phần mềm nhằm ứng dụng hiệu quả tại Việt Nam.

Tình hình nghiên cứu trong và ngoài nước

Năm 1975, Freed Brooks, một nhà quản lý dự án tại IBM, đã viết cuốn sách "The Mythical Man-Month" Trong tác phẩm này, ông trình bày những thách thức trong việc phát triển phần mềm phức tạp, đặc biệt thông qua một chương có tiêu đề nổi bật.

Trong bài viết "No Silver Bullet", tác giả nhấn mạnh rằng các hệ thống phần mềm có độ phức tạp cao và không có một kỹ thuật duy nhất nào có thể cải thiện năng suất cho tất cả các hệ thống Brooker chỉ ra rằng khủng hoảng phần mềm sẽ tiếp tục tồn tại cho đến khi các kỹ thuật mới, như kỹ thuật phần mềm dựa trên cấu phần (CBSE), trở nên có tính khoa học và được áp dụng một cách thực tiễn.

CBSE đã phát triển "Những bài học hay nhất" về sản phẩm công nghệ phần mềm trong 30 năm tới Brooks đề xuất hai phương pháp hiệu quả để giảm độ phức tạp của phần mềm: "Mua trước khi xây dựng" và "Tái sử dụng trước khi mua" Những khái niệm này nhằm mục đích giảm chi phí trong quá trình phát triển phần mềm.

Trong hội nghị NATO năm 1968, thuật ngữ khủng hoảng phần mềm được thảo luận, cùng với các khái niệm như kẽ hở phần mềm, dần được làm rõ trong quá trình phát triển công nghệ David và Fraser đã chỉ ra rằng "kẽ hở được phát hiện khi hậu quả của hỏng hóc phần mềm gia tăng theo mức độ nghiêm trọng." Để phát triển phần mềm dựa trên cấu phần, cần xây dựng chúng dựa vào yêu cầu hoặc thiết kế module thành phần Khách hàng đặt hàng các cấu phần và việc tích hợp từ nhà sản xuất sẽ đảm bảo đáp ứng đúng mong muốn của họ.

Mô hình cấu phần phần mềm, được phát triển bởi Brad Cox, đã tạo nền tảng cho hạ tầng phát triển các cấu phần này dựa trên ngôn ngữ lập trình C, như được trình bày trong cuốn sách "Object-Oriented Programming – An Evolution Approach" năm 1986.

IBM đã dẫn đầu trong nghiên cứu về Mô hình đối tượng hệ thống từ đầu những năm 1990, với những đóng góp quan trọng như OLE và COM trong phần mềm cấu phần Mô hình cấu phần phần mềm vẫn tiếp tục đạt được nhiều thành tựu đáng kể.

Mục tiêu của luận văn

Luận văn này nghiên cứu các kỹ thuật kiểm thử phần mềm và áp dụng các mô hình UML vào kiểm thử phần mềm dựa trên cấu phần Mục tiêu là chuyển giao các kết quả nghiên cứu lý thuyết thành thực nghiệm kiểm thử cho một thiết kế phần mềm cụ thể.

Nội dung nghiên cứu tập trung vào một số vấn đề sau:

1) Tổng quan về các vấn đề cơ bản của kiểm thử phần mềm, các nguyên tắc kiểm thử Tổng quan về phát triển phần mềm dựa trên cấu phần, bao gồm các khái niệm cơ bản như cấu phần, chuẩn tương tác, chuẩn kết hợp, cài đặt mô hình cấu phần, các mô hình cấu phần - dịch vụ cấu phần, tiếp cận UML, và vai trò của UML đặc tả thiết kế, ứng dụng vào kiểm thử

2) Nghiên cứu phương pháp luận kiểm thử phần mềm trên cơ sở cấu phần, bao gồm mô hình kiểm thử đối với phần mềm dựa trên cấu phần, kiểm thử tích hợp trên cơ sở các mô hình UML đối với phần mềm phát triển trên cấu phần Xây dựng các biểu đồ UML hỗ trợ ca kiểm thử tích hợp

3) Phát triển thực nghiệm kiểm thử phần mềm trên cơ sở sử dụng các cấu phần có sẵn dựa trên bài toán ứng dụng được đưa ra; xây dựng các pha phân tích, thiết kế và kiểm thử.

Một số khái niệm cơ bản

Phần mềm sử dụng cấu phần

Để nghiên cứu mục tiêu của luận văn, trước tiên cần tìm hiểu các thuật ngữ cơ bản trong CBSE, bắt đầu từ những khái niệm đơn giản nhất về cấu phần.

Phần tử phần mềm bao gồm chuỗi lệnh cấp cao và các phép toán mà máy tính thực hiện Để phần tử phần mềm được xem là thực thi, máy tính có thể thực hiện trực tiếp các lệnh hoặc thông qua một bộ thông dịch chuyển đổi các lệnh thành dạng mà máy có thể thực thi.

Mã nguồn phần mềm là tập hợp các tệp tin máy có thể đọc được, chứa các câu lệnh chương trình viết bằng ngôn ngữ lập trình Những câu lệnh này được chuyển đổi thành các câu lệnh thực thi thông qua bộ biên dịch hoặc bộ thông dịch.

Một cấu phần phần mềm là một tập các phần tử phần mềm được lập trình

Cấu phần phần mềm sau khi được cài đặt và đưa vào sử dụng có sự khác biệt rõ rệt so với phần tử phần mềm, thể hiện qua cách sử dụng Phần mềm bao gồm nhiều yếu tố trừu tượng và các đặc trưng chất lượng, là thước đo quan trọng để đánh giá xem một cấu phần hay quy trình có đáp ứng yêu cầu đặc tả hay không, theo chuẩn IEEE 610.12 – 1990 Thuật ngữ phần tử được sử dụng để mô tả cấu phần phần mềm trong bối cảnh này.

Cấu phần phần mềm là một đơn vị phần mềm tuân thủ mô hình cấu phần, có khả năng triển khai độc lập và có thể kết hợp với nhau mà không cần sửa đổi, theo một tiêu chuẩn kết hợp nhất định.

 Một mô hình cấu phần định nghĩa các đặc tả tương tác và các chuẩn kết hợp

Một cài đặt mô hình cấu phần bao gồm các phần tử phần mềm thiết yếu, nhằm hỗ trợ việc thực thi các cấu phần theo mô hình đã định.

Hạ tầng phần mềm bao gồm các cấu phần tương tác được thiết kế nhằm đảm bảo hệ thống phần mềm đáp ứng các yêu cầu về hiệu suất đã được xác định.

Các định nghĩa này thể hiện mối quan hệ quan trọng giữa hạ tầng của cấu phần phần mềm, các cấu phần phần mềm và mô hình cấu phần

Giao diện là một sự trừu tượng hóa dịch vụ, xác định các thao tác mà dịch vụ hỗ trợ và độc lập với bất kỳ sự thực thi nào Cấu phần phần mềm tương tác với thế giới bên ngoài thông qua giao diện của nó, cho phép người dùng hiểu rõ chức năng (what) mà không cần quan tâm đến cách thức thực hiện (how) bên trong Tài liệu mô tả giao diện cung cấp thông tin cần thiết về các thao tác, trong khi quy trình xử lý được ẩn hoàn toàn khỏi người sử dụng.

Chuẩn giao diện là các yêu cầu bắt buộc cho phần mềm, nhằm đảm bảo sự tương tác hiệu quả giữa các thành phần Nó quy định những gì có thể được chứa trong một giao diện, tạo điều kiện cho sự liên kết và hoạt động đồng bộ giữa các phần tử phần mềm.

Cấu phần cung cấp giao diện nếu nó cài đặt tất cả các thao tác được định nghĩa bởi giao diện đó Để yêu cầu một giao diện, cấu phần cần có sự tương tác được định nghĩa trong giao diện và giả định rằng có một phần mềm nào đó cung cấp giao diện này Nếu thiếu bất kỳ giao diện yêu cầu nào, cấu phần không thể cung cấp giao diện Do đó, cấu phần cần được triển khai với thông tin mô tả đầy đủ về tất cả các giao diện yêu cầu và giao diện cung ứng của nó.

Các phần tử phần mềm tương tác với nhau thông qua các giao diện được định nghĩa rõ ràng và tài liệu hóa Chuẩn tương tác xác định các phần tử của giao diện, và nếu một cấu phần chỉ có thể hoạt động thông qua việc tương tác với phần tử phần mềm khác, thì tất cả các phụ thuộc bối cảnh cần được mô tả chi tiết trong tài liệu cấu phần Chuẩn tương tác bao gồm cả các tương tác trực tiếp và gián tiếp giữa các cấu phần.

Một cấu phần phần mềm có thể có các phụ thuộc bối cảnh tường minh trên hệ điều hành, bao gồm yêu cầu về hiệu năng khi chạy trên máy tính với xung nhịp xác định Để tương tác với thiết bị phần cứng, các cấu phần sử dụng giao diện lập trình ứng dụng (APIs) của hệ điều hành hoặc giao diện của mô hình cấu phần Thông tin mô tả cấu phần cần định nghĩa rõ ràng các phụ thuộc bối cảnh này Để đảm bảo khả năng sử dụng lại và kết nối giữa các cấu phần, nhà sản xuất và người dùng cần thống nhất các giao diện trước khi thiết kế, dẫn đến việc chuẩn hóa các giao diện Các giao diện có thể được mô tả bằng nhiều ký pháp khác nhau, tùy thuộc vào thông tin và mức độ chi tiết mong muốn, nhưng phần giao diện chủ yếu chỉ cung cấp tên các phương thức, kiểu tham số và giá trị trả về, mà không đi vào từng thao tác đơn lẻ.

2.1.2 Chuẩn kết hợp Để có thể triển khai độc lập, cấu phần phải cách ly khỏi HĐH và các cấu phần khác Do đó, cấu phần phải đóng gói các thuật toán và dữ liệu cần thiết cho việc thực hiện nhiệm vụ của nó [3]

Cách thức một cấu phần được triển khai phụ thuộc mô hình cấu phần của nó, thông thường có ba bước triển khai sau:

2) Cấu hình cấu phần và HĐH, nếu cần

3) Đưa cấu phần vào sử dụng

Mã nguồn của cấu phần phần mềm là tất cả các file mà máy có thể đọc được

Các thủ tục, mô-đun và máy có khả năng thực thi các thư viện lúc thực thi cùng với mã đối tượng đã được biên dịch sẵn, tất cả được đóng gói thành các phần tử phần mềm có thể đọc được Một cấu phần phần mềm được đóng gói dưới dạng nhị phân nhằm mục đích tối ưu hóa hiệu suất và khả năng tương thích.

 Bảo vệ các thuộc tính mang đặc trưng riêng của nhà sản xuất cấu phần phần mềm

 Giảm chi phí cài đặt và triển khai

Giảm thiểu sự phụ thuộc vào bối cảnh tường minh là cần thiết, ví dụ như người dùng không cần phải sử dụng chương trình dịch Gnu C++ phiên bản 2.81 với các thành phần được đóng gói dưới dạng nhị phân.

Vòng đời phát triển phần mềm trên cơ sở cấu phần

Mặc dù công nghệ phần mềm dựa trên cấu phần (CBSE) được coi là nền tảng vững chắc trong ngành công nghiệp phần mềm, nhưng nó vẫn còn non nớt về mặt khoa học công nghệ Để đạt được thành công, các quy trình cần được chia sẻ như những bài thực hành tốt nhất, giúp nhiều tổ chức áp dụng CBSE hiệu quả hơn Một thách thức lớn là sự cạnh tranh giữa các tổ chức phát triển phần mềm và phòng dịch vụ thông tin về quy trình đã đăng ký Khi một nhà quản lý dịch vụ thông tin không thành công trong việc chuyển giao hệ thống phần mềm, họ có thể phải dựa vào nguồn lực bên ngoài Sự khác biệt chủ yếu giữa CBSE và phát triển phần mềm truyền thống nằm ở quy trình phát triển hệ thống phần mềm được áp dụng.

Quy trình xây dựng giải pháp được xác định bởi khách hàng hoặc doanh nghiệp, đặc biệt trong lĩnh vực công nghệ phần mềm Mô hình hóa quy trình nghiệp vụ là cách thức đạt được điều này Sự thỏa thuận giữa khách hàng và nhà thiết kế thông qua tài liệu hóa yêu cầu hoặc xem xét thiết kế là rất quan trọng Khi bắt đầu thiết kế giải pháp, các cấu phần sẽ có ảnh hưởng nhất định Nhóm xây dựng giải pháp đóng vai trò chủ đạo trong dự án, và một trong những lựa chọn cho thiết kế các cấu phần tương tác là sử dụng mô hình UML Thách thức đối với người xây dựng giải pháp là tích hợp các cấu phần thành một hệ thống lớn, yêu cầu thông tin về cấu phần, giao diện, dịch vụ, vận hành và phương thức.

Quy trình tìm kiếm các cấu phần phù hợp là rất quan trọng đối với nhà thiết kế, với thuật ngữ "lấp đầy khoảng trống" thường được sử dụng Quá trình này có thể dẫn đến hai kết luận: một là cấu phần giống như yêu cầu đã được tìm thấy và đưa vào sử dụng, hai là không có cấu phần nào như vậy tồn tại Điều này nhấn mạnh nhu cầu cần có một quy trình lưu trữ các cấu phần có sẵn và đôi khi cần tạo một dự án con để phát triển cấu phần theo đặc tả Quy trình lưu trữ không chỉ bao gồm các cấu phần đã xây dựng mà còn kích hoạt việc phát triển cấu phần mới Lợi ích thực sự của CBSE được thể hiện qua việc đồng thời triển khai giải pháp và phát triển cấu phần, đạt được thông qua lập kế hoạch và thiết kế Đối với các cấu phần không tìm thấy, quy trình lưu trữ cần cho phép khách hàng đưa ra yêu cầu để nhận được sự cung ứng thay thế.

Mỗi lần sử dụng một cấu phần, dù đã được đóng gói hay gắn vào sản phẩm, cần có quy trình quản lý cấu hình để theo dõi Các phiên bản mới có thể được cung cấp bất cứ lúc nào, và người xây dựng giải pháp cần cải tiến hoặc nâng cấp Khách hàng cũng cần được thông báo khi có bản cập nhật cho các cấu phần Việc thay thế cấu phần cũ bằng phiên bản mới sẽ dễ dàng hơn nếu người xây dựng đã đăng ký nhận thông báo về các bản cập nhật.

Vòng đời phát triển phần mềm và vòng đời cấu phần có sự khác biệt rõ rệt Trong phát triển phần mềm truyền thống, các nhà phát triển đảm nhận vai trò phân tích, thiết kế và lập trình, bắt đầu từ việc làm rõ yêu cầu và kết thúc khi hệ thống phần mềm được chuyển giao Ngược lại, vòng đời cấu phần yêu cầu thời gian nghiên cứu sâu về quy tắc nghiệp vụ và mô hình quy trình nghiệp vụ, mặc dù thời gian phát triển ngắn hơn, nhưng kiểm thử phải được thực hiện liên tục Để hiểu rõ hơn về vòng đời cấu phần, chúng ta cần xem xét định nghĩa chi tiết hơn.

Vòng đời phần mềm cấu phần (CSLC) mô tả quy trình phát triển phần mềm thông qua việc tích hợp các cấu phần bên ngoài CSLC tập trung vào các yếu tố quan trọng như quy tắc nghiệp vụ, mô hình quy trình nghiệp vụ, thiết kế, xây dựng, kiểm thử, triển khai, mở rộng, duy trì sử dụng lại và bảo trì Việc áp dụng CSLC giúp tối ưu hóa quy trình phát triển phần mềm, đảm bảo tính hiệu quả và bền vững trong suốt vòng đời sản phẩm.

Các giai đoạn phân tích và thiết kế trong Chu trình Sống của Phần mềm (CSLC) thường kéo dài hơn so với vòng đời phát triển phần mềm truyền thống, với hoạt động kiểm chứng được thực hiện ít nhất ở cuối mỗi pha Trong quá trình kiểm thử đơn vị, chúng ta áp dụng phương pháp cài đặt và kiểm thử tối ưu nhất Kiểm thử viên phần mềm làm việc chặt chẽ với các thành viên trong đội để thực hiện kiểm thử tích hợp và kiểm thử hệ thống Việc bảo trì được thiết kế cho các cấu phần nhằm hỗ trợ phát triển lâu dài Mô hình cấu phần được cài đặt để tạo điều kiện cho sự tương tác và kết hợp, giúp các kỹ sư xây dựng hạ tầng cấu phần phần mềm và xác định miền cho các cấu phần tương tác với các chức năng và hành vi của hệ thống trong CSLC.

Bảng dưới đây thể hiện so sánh giữa vòng đời phát triển phần mềm truyền thống với vòng đời phát triển CBSE

Bảng 1 So sánh vòng đời phát triển trên cơ sở cấu phần với vòng đời phát triển phần mềm truyền thống [3]

Bước Vòng đời phát triển phần mềm truyền thống

Vòng đời phát triển CBSE

1 Mô hình quy trình nghiệp vụ Mô hình quy trình nghiệp vụ

2 Quản lý yêu cầu Quản lý yêu cầu

3 Mô hình thiết kế hệ thống Mô hình thiết kế hệ thống (cấu phần)

CBSE Lấp đầy khoảng trống (gap fullfilled)

CBSE Đặc tả cấu phần mới

CBSE Đưa cấu phần vào sử dụng

CBSE Lập danh sách thư tín (liên hệ)

4 Lựa chọn môi trường phát triển tương tác (IDE - Interactive development environment)

Lựa chọn môi tường phát triển tương tác (IDE - Interactive development environment)

5 Xây dựng cơ sở dữ liệu Xây dựng cơ sở dữ liệu

6 Xây dựng tầng giữa Xây dựng tầng giữa

7 Xây dựng phần mềm khác Xây dựng phần mềm khác

CBSE Tiếp nhận cảnh báo, cấu phần mới

CBSE Xem xét cấu phần mới

CBSE Cập nhật thiết kế

12 Kết hợp các hệ thống Kết hợp các hệ thống

Các mô hình cấu phần và dịch vụ cấu phần

Cấu phần phần mềm ở mức ứng dụng có thể được sử dụng, nhưng khả năng tái sử dụng vẫn còn hạn chế Những hạn chế này xuất phát từ việc các ứng dụng quá thô và thiếu hỗ trợ kết hợp, trong khi hệ điều hành không có các chuẩn đặc tả miền rõ ràng Những thiếu sót này thể hiện qua một số đặc điểm cụ thể.

Thiếu tính chất hạt nhân trong các ứng dụng dẫn đến việc khó khăn trong việc cải thiện khả năng sử dụng lại Các nhà phát triển thường phải thiết kế các chức năng chung, nhưng CBSE (Component-Based Software Engineering) tìm ra các yếu tố chung để tích hợp vào hạ tầng cấu phần Mục tiêu của CBSE là phát triển các công nghệ chi tiết hơn và các cấu phần được tối ưu hóa, cho phép khả năng sử dụng lại tương tự như ở mức ứng dụng.

Thiếu sự hỗ trợ kết hợp trong các hệ điều hành khiến các ứng dụng thực thi độc lập, dẫn đến việc giao tiếp giữa chúng trở nên khó khăn Mặc dù có cơ chế như giao tiếp quy trình nội bộ để trao đổi dữ liệu, nhưng các giao diện ứng dụng thường thiếu sự rõ ràng và tiêu chuẩn kết hợp Các ứng dụng trong hệ điều hành chủ yếu xác định và sử dụng dịch vụ của hệ điều hành mà không phải là các đơn vị kết hợp hiệu quả.

Thiếu các chuẩn đặc tả miền trong hệ điều hành dẫn đến việc các dịch vụ trở nên quá chung chung, không đáp ứng được nhu cầu của các miền ứng dụng cụ thể Chẳng hạn, một hệ thống đồng bộ yêu cầu các dịch vụ và giao diện lập trình ứng dụng (APIs) khác biệt so với một hệ thống điều khiển quy trình hoặc ứng dụng viễn thông.

Mục tiêu của CBSE là phát triển phần mềm thông qua việc tạo ra các cấu phần có thể tái sử dụng, thay vì gắn chặt vào ứng dụng Để đạt được điều này, các cấu phần cần có chuẩn tương tác, kết hợp, và chuẩn hóa hạ tầng cùng dịch vụ CBSE định nghĩa các mô hình cấu phần theo các tiêu chuẩn này và cung cấp các cài đặt mô hình kết hợp, nhằm kích hoạt các cấu phần cùng hạ tầng được thiết kế, cài đặt và triển khai hiệu quả.

Cấu phần vận hành trên cơ sở các mô hình cấu phần Có hai mức vận hành cấu phần bao gồm: [3]

Mức thứ nhất: Một mô hình cấu phần định nghĩa cách xây dựng từng cấu phần riêng lẻ

Mô hình cấu phần điều khiển hoạt động của một tập hợp các cấu phần trong hệ thống thông qua giao tiếp và tương tác giữa chúng Nó định nghĩa một chuẩn tương tác và phát triển thành giao diện rõ ràng Một cấu phần có thể được hình thành từ các cấu phần khác hoặc các phần tử phần mềm khác bằng cách thiết lập các kết nối được tổ chức hoặc tích hợp riêng biệt.

Mô hình cấu phần định nghĩa cơ chế cấp phép cho việc tạo kết nối được tích hợp Theo D'Souza và Wills (1999), "khả năng lắp ghép" chỉ thành công khi một cấu phần chính xác biểu thị yêu cầu của cấu phần khác mà nó kết nối Quy trình này cần đủ phức tạp để đạt được kết quả đặc tả chính xác Chúng ta áp dụng khái niệm gắn kết cho các cấu phần như bao gói, liên kết tĩnh - động và "plug-and-play".

Mô hình cấu phần định nghĩa cơ chế tuỳ biến cho phép các cấu phần mở rộng mà không cần hiệu chỉnh, coi hiệu chỉnh là một dạng cải tiến tương tác Đồng thời, mô hình này cũng xác định các thuộc tính cấu phần bắt buộc như định dạng mã, chuẩn tài liệu và giao diện độc lập của nhà sản xuất.

Mô hình cấu phần xác định một tập hợp các chuẩn, bao gồm cài đặt, đặt tên, khả năng vận hành nội bộ, tùy biến, kết hợp, phát triển và triển khai Đồng thời, mô hình này cũng quy định các tiêu chuẩn cho việc triển khai mô hình liên kết các cấu phần, đảm bảo rằng các đối tượng phần mềm thực thi đáp ứng yêu cầu hỗ trợ cho các cấu phần theo mô hình đã định.

Hiện nay, một số mô hình cấu phần phổ biến bao gồm mô hình CORBA của OMG, COM+/DOM, SUN -javabean và Enterprise JavaBeans của Microsoft Mặc dù không bắt buộc phải tuân theo một chuẩn cụ thể khi phát triển cấu phần, nhưng việc có quá nhiều chuẩn cùng tồn tại tại một thời điểm có thể gây rối và khó khăn cho quá trình phát triển.

Mô hình cấu phần được Weinreich và Sametinger (2001) mô tả chi tiết các phần tử cơ bản Hình dưới đây tổng hợp các phần tử trong mô hình cấu phần, phân loại chúng theo các giao diện cấu phần, thông tin cần thiết để sử dụng trong chương trình và các yếu tố liên quan đến việc triển khai cấu phần.

Hình 1 Các phần tử cơ bản của một mô hình cấu phần[1]

Giao diện Thông tin cung cấp Triển khai và sử dụng Định nghĩa giao diện

Các giao diện đặc trưng Quy tắc đặt tên

Truy cập siêu dữ liệu

Sự tùy biến Đóng gói

Các phần tử cấu phần được xác định dựa trên giao diện của chúng Mô hình cấu phần mô tả cách định nghĩa các phần tử này, bao gồm tên hàm, tham số và các ngoại lệ Một số mô hình cấu phần yêu cầu giao diện đặc tả phải được định nghĩa bởi một cấu phần.

Một yếu tố quan trọng trong mô hình cấu phần là cách đóng gói và triển khai độc lập các cấu phần, nhằm đảm bảo các đối tượng thực hiện có thể hoạt động hiệu quả Do tính chất độc lập của các cấu phần, việc đóng gói phải không phụ thuộc vào hạ tầng cụ thể hoặc giao diện yêu cầu đã được định nghĩa.

2.3.1.1 Các phần tử của một mô hình cấu phần

Trong thị trường phần mềm toàn cầu, các cấu phần được triển khai độc lập và phụ thuộc vào sự kết hợp với bên thứ ba, đòi hỏi sự cần thiết của các chuẩn giao tiếp và trao đổi dữ liệu giữa các nhà sản xuất Một chuẩn hoạt động nội bộ, thường được gọi là chuẩn lắp ráp hoặc kết nối, đóng vai trò trung tâm trong mô hình cấu phần Các yếu tố cơ bản khác trong mô hình này bao gồm các chuẩn về giao diện, đặt tên, siêu dữ liệu, tùy biến, kết hợp, phát triển và triển khai.

Mô hình cấu phần có thể bao gồm các chuẩn đặc trưng để mô tả tính năng cần thiết trong ứng dụng Sự kết hợp giữa các cấu phần và các hoạt động trong miền yêu cầu tiếp cận các mô hình chuỗi chuẩn hóa cùng với cơ chế đồng bộ Hệ xử lý phân tán mở cần có các chuẩn về lời gọi phương thức từ xa và bảo mật, nhằm đảm bảo hiệu quả cho các ứng dụng nghiệp vụ.

UML trong phát triển phần mềm

Ngôn ngữ Mô hình thống nhất (UML) là tiêu chuẩn ngôn ngữ dùng để mô hình hóa các hệ thống trong thế giới thứ ba Hiện nay, UML vẫn giữ vai trò quan trọng trong việc mô hình hóa phần mềm, với nhiều lý do khiến nó trở thành công cụ phổ biến trong lĩnh vực này.

Mô hình là một công cụ đơn giản hóa thực tế, giúp chúng ta dễ dàng nắm bắt và hiểu rõ hơn về hệ thống cần xây dựng.

Mô hình hóa cho phép chúng ta đơn giản hóa và làm rõ bản chất của các vấn đề hoặc cấu trúc phức tạp bằng cách loại bỏ những chi tiết không cần thiết, từ đó giúp cho bài toán trở nên dễ hiểu và dễ tiếp cận hơn.

Việc biểu diễn mô hình thoả mãn các yếu tố sau:

 Chính xác (accurate): Mô tả đúng hệ thống cần xây dựng

 Đồng nhất (consistent): Các view khác nhau không được mâu thuẫn với nhau

 Có thể hiểu được (understandable): Cho cả người xây dựng lẫn sử dụng

 Dễ dàng liên hệ với các mô hình khác

Mục đích của UML là giúp người dùng xác định mô hình hệ thống, trong đó việc định nghĩa ngữ nghĩa của hệ thống đang phát triển là rất quan trọng Ngôn ngữ mô hình hóa thống nhất (UML) biểu diễn mô hình theo hướng đối tượng, nhằm mục đích tạo ra một cái nhìn rõ ràng và chính xác về hệ thống.

 Mô hình hoá các hệ thống, sử dụng các khái niệm hướng đối tượng

 Thiết lập một kết nối từ nhận thức của con người đến các sự kiện cần mô hình hoá

 Giải quyết vấn đề về mức độ thừa kế trong các hệ thống phức tạp, có nhiều ràng buộc khác nhau

 Tạo một ngôn ngữ mô hình hoá có thể sử dụng được bởi người và máy

Sử dụng UML giúp người dùng tạo ra mô hình ứng dụng hoàn chỉnh, ổn định và chính xác Nếu thực hiện đúng, mô hình này có thể được kiểm chứng qua phân tích hoặc thực hiện, đồng thời hỗ trợ tạo ra mã nguồn để triển khai hệ thống Việc tự động sinh mã code thông qua các công cụ như Rhapsody mang lại nhiều lợi ích, bao gồm giảm thiểu nguồn lực và duy trì tính ổn định giữa mô hình UML và mã lệnh, góp phần tạo nên hệ thống cuối cùng.

Hiện nay UML là yếu tố chuẩn áp dụng cho việc mô hình hoá phần mềm Có rất nhiều cơ sở để khẳng định điều này:

UML có một mô hình ngữ nghĩa nền tảng rõ ràng, gọi là siêu mô hình UML, bao quát hầu hết các lĩnh vực cần thiết cho tiêu chuẩn kỹ thuật và thiết kế hệ thống Mô hình này không chỉ rộng mà còn sâu, cho phép tạo ra các mô hình có thể triển khai hoặc phục vụ cho việc chuyển đổi ngôn ngữ lập trình Nhờ đó, lập trình viên có thể dễ dàng có được mô hình của bất kỳ hệ thống nào mà họ cần và thể hiện một cách hiệu quả.

UML sử dụng các ký hiệu chuyên nghiệp và dễ hiểu, mặc dù một số người cho rằng có quá nhiều loại biểu đồ Trên thực tế, chỉ có một số biểu đồ thường được sử dụng như: biểu đồ cấu trúc (lớp), biểu đồ triển khai, biểu đồ trạng thái, biểu đồ hoạt động, biểu đồ các ca sử dụng và biểu đồ tuần tự Các biểu đồ này hoạt động theo phương thức rõ ràng và tuân theo một số nguyên tắc chung.

UML được sử dụng như một chuẩn giúp lập trình viên lựa chọn công cụ và dịch vụ từ nhiều nguồn khác nhau.

UML, với vai trò là ngôn ngữ mô hình hóa hướng đối tượng, đã chứng minh khả năng ứng dụng rộng rãi trong nhiều lĩnh vực Chúng ta đã tích lũy được nhiều thập kỷ kinh nghiệm trong việc áp dụng các phương pháp hướng đối tượng vào phát triển hệ thống, bao gồm cả hệ thống nhúng và hệ thống thời gian thực.

Hiện nay, UML được áp dụng rộng rãi trong việc xây dựng các mô hình và hệ thống, từ những dự án đơn giản đến các hệ thống nhúng và thời gian thực Việc không sử dụng UML có thể dẫn đến những khó khăn nhất định cho các lập trình viên trong quá trình phát triển hệ thống.

2.4.2 Vai trò, vị trí của các lược đồ UML trong vòng đời phần mềm

UML là một công cụ quan trọng trong nhiều giai đoạn của quy trình phát triển phần mềm, từ thiết kế đến thực thi và bảo trì Ngôn ngữ này sử dụng các biểu đồ hướng đối tượng để mô tả các hệ thống, do đó, UML có thể áp dụng cho nhiều loại hệ thống khác nhau, bao gồm hệ thống thông tin, hệ thống kỹ thuật, hệ thống nhúng, hệ thống phân bố, hệ thống giao dịch và phần mềm hệ thống.

UML có mặt trong hầu hết các giai đoạn phát triển hệ thống:

Nghiên cứu sơ bộ về use cases giúp xác định các yêu cầu của người dùng Phần mô tả use case cung cấp thông tin chi tiết về các yêu cầu, trong khi phần diagram minh họa mối quan hệ và cách thức giao tiếp với hệ thống.

Giai đoạn này tập trung vào việc trừu tượng hóa và phân tích các cấu trúc trong bài toán Class diagrams giúp làm rõ các thực thể thực tế, đồng thời thể hiện sự tồn tại và mối quan hệ giữa chúng Chỉ những lớp (class) liên quan đến bài toán mới được xem xét và chú trọng.

Thiết kế: Kết quả phần analysis được phát triển thành giải pháp kỹ thuật

Các lớp được thiết kế chi tiết nhằm cung cấp hạ tầng kỹ thuật như giao diện và nền tảng cho cơ sở dữ liệu Kết quả của giai đoạn thiết kế là các đặc tả chi tiết phục vụ cho quá trình xây dựng phần mềm.

Phát triển: Mô hình Design được chuyển thành code Lập trình viên sử dụng các UML diagrams trong giai đoạn Design để hiểu vấn đề và tạo code

Kiểm thử: Sử dụng các UML diagrams trong các giai đoạn trước Có 4 hình thức kiểm tra hệ thống:

 Kiểm thử đơn vị (class diagrams & class specifications) : kiểm tra từng đơn thể, được dùng để kiểm tra các lớp hay các nhóm đơn thể

Kiểm thử tích hợp là quá trình kiểm tra sự kết hợp giữa các cấu phần và các lớp trong hệ thống để đảm bảo chúng hoạt động một cách chính xác và hiệu quả với nhau Việc sử dụng các sơ đồ tích hợp và sơ đồ hợp tác giúp hình dung rõ ràng hơn về mối quan hệ và tương tác giữa các thành phần, từ đó nâng cao chất lượng và độ tin cậy của hệ thống.

 Kiểm thử hệ thống (use-case diagrams) : kiểm tra xem hệ thống có đáp ứng được chức năng mà người dùng yêu cầu hay không

Lý thuyết kiểm thử

2.5.1 Tại sao kiểm thử là cần thiết? [2]

Ngày nay, phần mềm đã trở thành một phần không thể thiếu trong cuộc sống hàng ngày của chúng ta, từ việc sử dụng tại nhà, trong công việc, cho đến khi đi mua sắm Chúng ta áp dụng phần mềm trong nhiều lĩnh vực như ngân hàng và các sản phẩm tiêu dùng như ô tô hay máy rửa bát Tuy nhiên, trong quá trình sử dụng, người dùng có thể gặp phải một số rủi ro như lỗi hóa đơn trong giao dịch mua bán, sự chậm trễ trong xử lý thẻ tín dụng, hoặc website không tải được.

Không phải tất cả các hệ thống phần mềm đều có cùng mức rủi ro và không phải mọi vấn đề đều có ảnh hưởng giống nhau khi rủi ro xảy ra Rủi ro là một khả năng chưa xảy ra, có thể sẽ không bao giờ xảy ra, và nó thể hiện một vấn đề tiềm tàng Chúng ta thường lo lắng về những vấn đề có khả năng xảy ra, vì khi một rủi ro xuất hiện, nó có thể gây ra tác động tiêu cực Do đó, khi bàn về rủi ro, cần xem xét cách thức xảy ra và các ảnh hưởng của nó.

Việc sử dụng phần mềm thường xuyên có thể dẫn đến chi phí cao, trong khi lỗi phần mềm không chỉ gây thiệt hại về tài chính và thời gian mà còn ảnh hưởng đến danh tiếng doanh nghiệp Đặc biệt, một số lỗi nghiêm trọng có thể gây ra hậu quả lớn cho cá nhân, bao gồm cả thương tích hoặc thậm chí tử vong.

Nếu tôi viết sai tên thời con gái của bà ngoại trên trang web cây phả hệ gia đình, mẹ tôi sẽ rất giận và tôi sẽ bị cả gia đình chê cười Tuy nhiên, tôi có thể dễ dàng sửa chữa sai sót này và đảm bảo rằng chỉ gia đình tôi biết về điều đó.

Một trang web công ty với lỗi chính tả có thể khiến khách hàng đánh giá thấp tính chuyên nghiệp của công ty, dẫn đến việc trì hoãn nghiệm thu sản phẩm.

Nếu một chương trình phần mềm tính toán sai, nó có thể dẫn đến những lỗi nghiêm trọng ảnh hưởng đến chất lượng phần mềm Chẳng hạn, nếu dấu phẩy động bị đặt sai vị trí, tỷ lệ trong ứng dụng có thể thay đổi gấp nhiều lần, gây ra hậu quả lớn cho người dùng.

Kiểm thử là một bước quan trọng không thể thiếu trong quy trình phát triển phần mềm, giúp đảm bảo chất lượng sản phẩm và giảm thiểu rủi ro không cần thiết.

2.5.2 Nguyên nhân gây lỗi phần mềm

2.5.2.1 Chúng ta có gây ra các sai lầm khi phát triển phần mềm?

Bất kỳ ai, bao gồm lập trình viên và nhân viên kiểm thử, đều có thể gây ra sai sót, dẫn đến lỗi trong mã chương trình, hệ thống hoặc tài liệu Những lỗi này có thể làm hệ thống thất bại, vì vậy các sai sót mà chúng ta tạo ra ảnh hưởng trực tiếp đến sản phẩm mà chúng ta chịu trách nhiệm Các sai sót có thể nghiêm trọng do tính phức tạp của phần mềm và dự án, nơi nhiều sản phẩm và kết quả cuối cùng được hình thành Trong quá trình xây dựng, một số sai sót có thể được phát hiện và loại bỏ, nhưng việc tìm ra lỗi trong sản phẩm là rất khó khăn Lỗi trong phần mềm, hệ thống hoặc tài liệu có thể dẫn đến hỏng hóc, tuy nhiên không phải tất cả lỗi đều gây ra sự cố nghiêm trọng.

Khả năng ra quyết định của con người thường bị ảnh hưởng bởi nhiều yếu tố như thiếu kinh nghiệm, thông tin không chính xác, và sự mệt mỏi Khi không cẩn thận hoặc cảm thấy không hài lòng, não bộ có thể không xử lý thông tin một cách hiệu quả, dẫn đến những quyết định nhạy cảm không chính xác.

Ngoài ra, chúng ta còn đối mặt với nhiều lỗi phát sinh từ sự phức tạp kỹ thuật, bao gồm các vấn đề liên quan đến nghiệp vụ, quy trình nghiệp vụ phức tạp, mã nguồn, hạ tầng, cũng như sự thay đổi kỹ thuật và nhiều tương tác giữa các hệ thống.

Hỏng hóc trong hệ thống không chỉ do lỗi kỹ thuật mà còn có thể xuất phát từ các điều kiện môi trường như bức xạ, từ trường mạnh hoặc ô nhiễm Những yếu tố này có thể gây ra lỗi trong phần cứng và vi xử lý, làm ảnh hưởng đến hiệu suất của phần mềm Ngoài ra, sai sót cũng có thể do người dùng tương tác sai với hệ thống, chẳng hạn như nhập giá trị đầu vào không chính xác hoặc nhận kết quả đầu ra sai lệch.

Khi ta nghĩ đến những gì có thể làm sai hướng ta phải nghĩ đến lỗi và những hỏng hóc phát sinh từ:

 Lỗi trong đặc tả, thiết kế và cài đặt phần mềm hệ thống

 Lỗi trong khi sử dụng hệ thống

 Các điều kiện môi trường

 Hậu quả của các sai sót sớm, thiệt hại do cố ý, lỗi và các hỏng hóc;

2.5.2.2 Khi nào thì xảy ra lỗi?

Hình dưới ta có thể thấy được số các lỗi có thể phát sinh theo 4 dạng khai thác yêu cầu trong một sản phẩm

Hình 3 Các tình huống phát sinh lỗi trong quá trình phát triển phần mềm Đặc tả yêu cầu đúng

Thiết kế đáp ứng được yêu cầu

Xây dựng đúng theo thiết kế

Sản phẩm đúng theo mong đợi

Các yêu cầu chức năng và phi chức năng bàn giao đúng theo mong đợi.

Yêu cầu 1 Đặc tả yêu cầu đúng

Thiết kế đáp ứng được yêu cầu

Các lỗi chương trình cần được sửa

Lỗi trong bước xây dựng

Sản phẩm có chứa lỗi Đặc tả yêu cầu đúng

Xây dựng đúng thiết kế

Sản phẩm có khiếm khuyết thiết kế

Thiết kế lại để sửa lỗi

Lỗi bước đặc tả yêu cầu

Thiết kế đúng theo xây dựng yêu cầu

Chương trình xây dựng đúng theo thiết kế

Sản phẩm bàn giao bị sai.

Lỗi có thể tiềm ẩn trong nhóm phát triển bao gồm cả kiểm thử viên

Yêu cầu đầu tiên cần được thực hiện chính xác là hiểu rõ nhu cầu của khách hàng, thiết kế sản phẩm phù hợp và xây dựng đúng theo thiết kế đó Việc phát triển các yêu cầu dựa trên thuộc tính và chức năng sẽ giúp sản phẩm đáp ứng được các giả định cũng như các thuộc tính phi chức năng Kết quả là sản phẩm sẽ thân thiện và dễ hiểu cho người dùng, đảm bảo rằng tất cả yêu cầu đã được thực hiện đầy đủ.

Trong quá trình phát triển yêu cầu số 2, các sai sót và lỗi có thể xuất hiện trong giai đoạn lập trình Những sai sót này để lại dấu vết và thường được phát hiện và sửa chữa trong quá trình kiểm thử Do đó, sản phẩm trước khi kiểm thử thường không đáp ứng đầy đủ các đặc tả thiết kế.

Các lỗi trong yêu cầu số 3 thường khó phát hiện hơn, vì chúng ta đã xây dựng dựa trên những gì đã đề ra Tuy nhiên, thiết kế có thể phát sinh sai sót, dẫn đến việc lỗi vẫn tồn tại trong quá trình phát triển Nếu không kiểm tra lại các yêu cầu định nghĩa, chúng ta sẽ khó phát hiện lỗi trong quá trình kiểm thử Khi lỗi được phát hiện, việc sửa chữa sẽ trở nên phức tạp hơn do thiết kế cần phải thay đổi.

Các lỗi trong yêu cầu số 4 thường xảy ra khi định nghĩa các yêu cầu cho sản phẩm Nếu sản phẩm được thiết kế và xây dựng đáp ứng các yêu cầu này, quá trình kiểm thử sẽ thành công Tuy nhiên, sản phẩm vẫn có thể bị khách hàng hoặc người dùng cuối loại bỏ Những lỗi này thường được phát hiện khi khách hàng thực hiện kiểm thử nghiệm thu hoặc đưa sản phẩm vào sử dụng, dẫn đến chi phí phát hiện lỗi ở giai đoạn này rất cao Theo đánh giá từ hàng ngàn dự án, lỗi trong yêu cầu và thiết kế chiếm tới một nửa tổng số lỗi dự án, cho thấy tầm quan trọng của việc hiểu rõ yêu cầu và thiết kế ngay từ đầu.

2.5.2.3 Chi phí sửa lỗi là gì?

Kiểm thử trên cơ sở các mô hình UML

Thực nghiệm kiểm thử phần mềm