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

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 hết 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 nhỏ nhất và đơn giản nhất về các 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 Nó được coi là thực thi khi máy tính thực hiện trực tiếp các lệnh hoặc khi một bộ thông dịch hoạt động trên máy tính để chuyển đổi các câu lệnh thành đị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 có thể đọc được, chứa các câu lệnh chương trình được viết bằng ngôn ngữ lập trình Các 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 được cài đặt và đưa vào sử dụng, với sự khác biệt giữa phần tử phần mềm và cấu phần phần mềm nằm ở 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 để đánh giá xem một cấu phần hay quy trình có đáp ứng yêu cầu đặc tả theo chuẩn IEEE 610.12 – 1990 hay không Thuật ngữ phần tử được sử dụng trong phạm vi mô tả cấu phần phần mềm.

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

 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 cần thiết để đảm bảo việc thực thi các cấu phần theo mô hình một cách hiệu quả.

Hạ tầng phần mềm là tập hợp 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 đặc tả 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ụ, định nghĩa các thao tác mà dịch vụ hỗ trợ, và độc lập với sự thực thi cụ thể Cấu phần phần mềm giao tiếp với thế giới bên ngoài thông qua giao diện của nó, với tài liệu đặc tả giao diện cho biết chức năng (what) mà nó thực hiện Nội dung mã thực thi và quy trình xử lý (how) được ẩn hoàn toàn, giúp người sử dụng không cần quan tâm đến cách thức hoạt động của cấu phần.

Chuẩn giao diện là các yêu cầu bắt buộc cho phần mềm, giúp các phần tử tương tác trực tiếp với nhau Nó xác định rõ ràng nội dung có thể chứa trong giao diện.

Cấu phần cung cấp giao diện cung ứng khi nó cài đặt đầy đủ các thao tác được định nghĩa bởi giao diện đó Để tương tác hiệu quả, một cấu phần cần có giao diện yêu cầu, giả định rằng có phần mềm nào đó sẽ 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 sẽ không thể cung cấp giao diện cung ứng Do đó, việc triển khai cấu phần cần phải có thông tin mô tả chi tiết 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 cấu phần 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 định nghĩa các phần tử của giao diện, và nếu cấu phần chỉ có thể thực hiện chức năng thông qua 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ả tường minh trong tài liệu 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 có thể có phụ thuộc bối cảnh tường minh trên hệ điều hành, phần mềm hoặc phần tử phần mềm khác Chuẩn tương tác xác định các phụ thuộc này, bao gồm yêu cầu về xung nhịp máy tính để đạt hiệu năng mong muốn Khi tương tác với thiết bị phần cứng, cấu phần sử dụng các giao diện lập trình ứng dụng (APIs) của hệ điều hành hoặc giao diện 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 Để tái sử dụng và kết nối giữa các cấu phần, nhà sản xuất và người dùng phải thống nhất các giao diện trước khi thiết kế, dẫn đến các giao diện chuẩn hóa 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, chỉ cung cấp tên phương thức, kiểu tham số và giá trị trả về, mà không mô tả 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ấu phần phần mềm được đóng gói dưới dạng nhị phân bao gồm 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ạo thành các yếu tố phần mềm mà máy có thể đọc được.

 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, chẳng hạn như việc người dùng không cần chương trình dịch Gnu C++ phiên bản 2.81 khi sử dụng 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 xem 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 trẻ 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 thực hành tốt nhất, giúp nhiều tổ chức áp dụng CBSE hiệu quả hơn Tuy nhiên, các tổ chức phát triển phần mềm và phòng dịch vụ thông tin thường gặp phải sự cạnh tranh về quy trình đã được đăng ký Khi một nhà quản lý dịch vụ thông tin thất bại trong việc chuyển giao hệ thống phần mềm, họ có thể chọn sử dụng toàn bộ nguồn lực bên ngoài Nếu nguồn lực sẵn có và công cụ phát triển không khác biệt so với phát triển phần mềm truyền thống, thì điểm khác biệt chủ yếu nằm ở quy trình phát triển hệ thống phần mềm.

Quy trình xây dựng giải pháp trong lĩnh vực công nghệ phần mềm, theo Allen và Frost (1998), bắt nguồn từ yêu cầu của khách hàng hoặc doanh nghiệp (Eles và Sims, 1998) và thường được thực hiện thông qua việc mô hình hóa quy trình nghiệp vụ (Jacobson 1994) Sự thỏa thuận giữa khách hàng và nhà thiết kế được xác lập qua việc tài liệu hóa các yêu cầu hoặc xem xét các thiết kế Mỗi lần thiết kế giải pháp bắt đầu, các cấu phần sẽ có ảnh hưởng nhất định, và nhóm chịu trách nhiệm xây dựng giải pháp sẽ là yếu tố quyết định cho dự án 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 lớn nhất cho 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, điều này đòi hỏi thông tin về các cấu phần có sẵn, giao diện yêu cầu, dịch vụ, hoạt động 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ế, thường được gọi là lấp đầy khoảng trống Quá trình này có thể dẫn đến hai kết luận: một là cấu phần cần thiết đã được tìm thấy và có thể sử dụng, hai là không có cấu phần nào tồn tại Điều này nhấn mạnh sự cần thiết của một quy trình lưu trữ các cấu phần có sẵn, đồng thời có thể yêu cầu xây dựng một dự án con để phát triển cấu phần theo yêu cầu cụ thể Quy trình lưu trữ không chỉ lưu giữ các cấu phần đã có mà còn khuyến khích việc phát triển cấu phần mới Lợi ích thực sự của việc phát triển cấu phần (CBSE) chỉ được nhận ra khi kết hợp giữa giải pháp và phát triển cấu phần, điều này cần được thực hiện 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 các giải pháp thay thế.

Mỗi khi sử dụng một cấu phần, dù đã được đóng gói hay gắn vào sản phẩm, việc quản lý cấu hình là cần thiết 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ó quy trình thông báo cho khách hàng về các cập nhật Điều này giúp họ dễ dàng thay thế cấu phần cũ bằng phiên bản mới hơn, miễn là họ đã đăng ký nhận thông báo khi có phiên bản mới được lưu trữ.

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 vòng đời 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, với một khởi đầu rõ ràng về 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 quy tắc nghiệp vụ và mô hình quy trình nghiệp vụ nhiều hơn, trong khi thời gian phát triển lại ngắn hơn, nhưng kiểm thử phải diễn ra 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 tích hợp cấu phần bên ngoài, bao gồm các giai đoạn 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ì CSLC là một khung tổng thể giúp đảm bảo hiệu quả và chất lượng trong quá trình phát triển phần mềm.

Các giai đoạn phân tích và thiết kế trong Chu trình Sống của Thành phần (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 Kiểm chứng được thực hiện ít nhất vào cuối mỗi giai đoạn của CSLC 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 Các kiểm thử viên phần mềm làm việc chặt chẽ với tất 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 xác định nhằm đảm bảo phát triển bền vững Mô hình cấu phần hỗ trợ sự tương tác và kết hợp, giúp các kỹ sư xây dựng hạ tầng phần mềm và xác định miền cho các cấu phần tương tác với 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 ở mức ứng dụng có thể được sử dụng, nhưng khả năng tái sử dụng của chúng còn hạn chế do các ứng dụng quá thô và thiếu hỗ trợ kết hợp Hơn nữa, hệ điều hành cũng chưa có các chuẩn đặc tả miền rõ ràng, dẫn đến những thiếu sót trong việc sử dụng lại Những vấn đề này được 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 sử dụng lại gặp khó khăn, vì các nhà phát triển thường phải thiết kế các chức năng chung cho mọi ứng dụng CBSE (Component-Based Software Engineering) tìm kiếm các yếu tố chung để tích hợp vào các dịch vụ từ mô hình cấu phần đã được cài đặt Tư tưởng trọng tâm của CBSE là phát triển các công nghệ chi tiết hơn, giúp tạo ra các cấu phần mịn màng hơn, từ đó nâng cao khả năng sử dụng lại ở cấp độ ứng dụng tương tự như ở cấp độ cấu phần.

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 khó khăn trong việc trao đổi dữ liệu qua giao tiếp quy trình nội bộ Mặc dù có khả năng giao tiếp giữa các ứng dụng, nhưng các giao diện ứng dụng thường thiếu sự đặc tả rõ ràng và tiêu chuẩn kết hợp Các ứng dụng triển khai trong hệ điều hành chỉ định và sử dụng các dịch vụ của hệ điều hành đó, nhưng hiếm khi hoạt động như những đơ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 ứ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 một ứng dụng viễn thông.

Mục tiêu của CBSE là phát triển hệ thống 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, tách biệt thay vì gắn vào ứng dụng Các cấu phần này cần có chuẩn tương tác và kết hợp, cùng với việc chuẩn hóa hạ tầng và dịch vụ CBSE tham gia vào việc định nghĩa các mô hình cấu phần theo các chuẩn này và cung cấp các cài đặt mô hình cấu phần kết hợp, nhằm kích hoạt các cấu phần và hạ tầng cấu phần đượ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 chung của một tập cấu phần trong hệ thống dựa trên sự giao tiếp và tương tác giữa chúng Nó định nghĩa một chuẩn tương tác, nâng cao thành giao diện đặc tả tường minh Các cấu phần có thể được tạo ra từ cấu phần khác hoặc các phần tử phần mềm khác thông qua việc thiết lập các kết nối được tập hợp hoặc tích hợp riêng.

Mô hình cấu phần xác định cơ chế cấp phép cho việc tạo các kết nối 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 thể hiện chính xác 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 để đảm bảo 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ác cơ chế tuỳ biến cho phép mở rộng cấu phần mà không cần hiệu chỉnh Hiệu chỉnh được coi là một dạng cải tiến tương tác Ngoài ra, 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 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 Nó cũng thiết lập tiêu chuẩn cho việc triển khai mô hình liên kết các cấu phần, yêu cầu các đối tượng phần mềm thực thi hỗ trợ cho việc thực hiện 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 tiêu chuẩn cụ thể khi phát triển cấu phần, nhưng việc có quá nhiều tiêu chuẩn cùng tồn tại tại một thời điểm là không nên.

Mô hình cấu phần do Weinreich và Sametinger (2001) liệt kê các phần tử cơ bản, được phân loại theo các giao diện cấu phần Hình ảnh dưới đây tổng hợp các phần tử này, bao gồm các yếu tố liên quan đến thông tin cần thiết để sử dụng cấu phần trong chương trình và các phần tử tập trung vào 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 qua giao diện của chúng Mô hình cấu phần chỉ ra cách thức đị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 yêu cầu giao diện đặc tả phải được định nghĩa bởi một cấu phần cụ thể.

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

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

Trong thị trường cấu phần phần mềm toàn cầu, việc triển khai các cấu phần độc lập và sự kết hợp với bên thứ ba là rất quan trọng Để đảm bảo tính tương thích, cần có các chuẩn giao tiếp và chuẩn trao đổi dữ liệu rõ ràng giữa các nhà sản xuất Một chuẩn hoạt động nội bộ, hay còn 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 Ngoài ra, các chuẩn khác như giao diện, đặt tên, siêu dữ liệu, tuỳ biến, kết hợp, phát triển và triển khai cũng là những phần tử cơ bản không thể thiếu trong mô hình này.

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 các cấu phần trong các miền và các hoạt động yêu cầu tiếp cận các mô hình chuỗi chuẩn hóa và cơ chế đồng bộ Hệ xử lý phân tán mở cần có các chuẩn gọi phương thức từ xa và chuẩn bảo mật để đảm bảo hiệu quả trong 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ữ được sử dụng để mô hình hóa các hệ thống phần mềm UML đóng vai trò quan trọng trong việc mô hình hóa phần mềm nhờ vào khả năng biểu diễn các khía cạnh khác nhau của hệ thống một cách trực quan và dễ hiểu Sự phổ biến của UML trong lĩnh vực phần mềm xuất phát từ nhiều lý do, bao gồm tính linh hoạt, khả năng giao tiếp giữa các nhà phát triển và người dùng, cũng như hỗ trợ trong việc thiết kế và phân tích hệ thống.

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

Mô hình hóa giúp đơn giản hóa và làm rõ bản chất của vấn đề hoặc cấu trúc phức tạp bằng cách loại bỏ các chi tiết không cần thiết, từ đó giúp người đọc dễ hiểu và tiếp cận bài toán một cách hiệu quả 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 của 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 biểu diễn mô hình theo hướng đối tượng, nhằm phục vụ cho việc phát triển hệ thống hiệu quả.

 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

Việc 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 Mô hình này có thể được kiểm chứng qua phân tích và thực hiện, đồng thời hỗ trợ trong việc tạo ra mã nguồn cho hệ thống Sử dụng các công cụ như Rhapsody cho phép tự động sinh mã code, mang lại nhiều lợi ích như 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, từ đó góp phần vào việc phát triển hệ thống hiệu quả hơn.

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, được gọi là siêu mô hình UML, bao quát hầu hết các lĩnh vực 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 sử dụng để phát triển mã nguồn cho việc chuyển đổi ngôn ngữ Nhờ đó, lập trình viên có thể dễ dàng truy cập và thể hiện bất kỳ mô hình nào của hệ thống mà họ cần.

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 đồ Thực tế, chỉ có một số biểu đồ thường xuyên đượ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 là một chuẩn quan trọng 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 khả năng ứng dụng rộng rãi, đã trở thành ngôn ngữ mô hình hóa hướng đối tượng hàng đầu Chúng ta có nhiều thập kỷ kinh nghiệm trong việc áp dụng các phương thức 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.

Ngày 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ể khiến các lập trình viên gặp phải nhiều khó khăn trong quá trình phát triển hệ thống của họ.

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 ngôn ngữ mạnh mẽ được áp dụ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ì Với mục đích chính là sử dụng các biểu đồ hướng đối tượng để mô tả hệ thống, UML phù hợp 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 phối, 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 case giúp xác định các yêu cầu của người dùng một cách rõ ràng Phần mô tả use case nêu bật các yêu cầu cụ thể, trong khi phần diagram minh họa mối quan hệ và cách thức giao tiếp giữa người dùng và hệ thống.

Giai đoạn này nhằm 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ể ngoài đời thực, 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 trực tiếp đến phạm vi bài toán mới cần được chú ý.

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ế tỉ mỉ nhằm cung cấp hạ tầng kỹ thuật cần thiết, bao gồm 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, bao gồm các sơ đồ tích hợp và sơ đồ hợp tác, là quá trình kiểm tra sự kết hợp giữa các thành phần và các lớp để đảm bảo chúng hoạt động hài hòa với nhau.

 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 quan trọng trong cuộc sống hàng ngày của chúng ta, từ công việc, mua sắm đến giao tiếp Chúng ta sử dụng phần mềm cho nhiều hoạt động như ngân hàng và các sản phẩm tiện ích như ô tô hay máy rửa bát Tuy nhiên, lĩnh vực phần mềm cũng tiềm ẩn nhiều rủi ro, chẳng hạn như lỗi hóa đơn trong giao dịch, sự chậm trễ trong xử lý thẻ tín dụng, hoặc trang web không tải được.

Không phải tất cả các hệ thống phần mềm đều có mức rủi ro giống nhau và các vấn đề cũng không có ảnh hưởng đồng nhất khi rủi ro xảy ra Rủi ro là một tình huống tiềm ẩn có thể không bao giờ xảy ra, và chúng ta thường lo lắng về những vấn đề có khả năng xảy ra Khi một rủi ro diễn ra, nó có thể gây ra những 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 và lỗi phần mềm gây ra thiệt hại đáng kể, bao gồm tổn thất về tài chính, thời gian và ảnh hưởng tiêu cực đến danh tiếng doanh nghiệp Trong một số trường hợp nghiêm trọng, lỗi phần mềm còn có thể gây ra hậu quả lớn đến sức khỏe cá nhân, thậm chí dẫn đến thương tích hoặc 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ỉ có gia đình tôi biết về điều đó.

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

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

Kiểm thử là một bước quan trọng trong quy trình sản xuất 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, từ lập trình viên đến nhân viên kiểm thử, đều có thể gây ra sai sót dẫn đến lỗi trong mã, hệ thống hoặc tài liệu Những lỗi này có thể khiến hệ thống gặp sự cố, do đó, sai sót là một phần không thể tránh khỏi trong quá trình phát triể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 vì phần mềm và dự án thường rất phức tạp, với nhiều sản phẩm và giai đoạn khác nhau Dù một số lỗi có thể được phát hiện và sửa chữa trong quá trình xây dựng, nhưng không phải lúc nào cũng dễ dàng nhận ra chúng Mặc dù 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, 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 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, sự thiếu hiểu biết, cũng như trạng thái tinh thần như mệt mỏi hoặc không hài lòng Những yếu tố này có thể làm giảm khả năng xử lý thông tin của não bộ, dẫn đến những quyết định không nhạy bén.

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

Các 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 hoặc vi xử lý, ảnh hưởng đến hiệu suất của phần mềm Ngoài ra, sai sót cũng có thể xảy ra do lỗi của người dù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

Để đảm bảo yêu cầu số 1 được thực hiện đúng, chúng ta cần hiểu rõ yêu cầu của khách hàng và thiết kế sản phẩm sao cho đáp ứng đầy đủ các yêu cầu đó, bao gồm cả thuộc tính và chức năng Sản phẩm cuối cùng sẽ phải phù hợp với các giả định và thuộc tính phi chức năng, đảm bảo tính thân thiện và dễ hiểu cho người dùng Đối với yêu cầu số 2, quá trình phát triển diễn ra bình thường cho đến giai đoạn lập trình, tuy nhiên, trong giai đoạn này có thể phát sinh một số sai sót và lỗi Những sai sót này sẽ được ghi nhận và sửa chữa trong quá trình kiểm thử, vì vậy sản phẩm trước khi kiểm thử có thể không hoàn toàn đáp ứng được các tiêu chuẩn thiết kế đã đề ra.

Các lỗi trong yêu cầu số 3 thường khó xác định hơn, vì chúng ta thực hiện đúng theo những gì đã đề ra, nhưng thiết kế lại mắc sai sót Do đó, lỗi này tiếp tục 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 khó có thể phát hiện những lỗi này trong giai đoạn kiểm thử Khi phát hiện ra lỗi, việc sửa chữa sẽ trở nên phức tạp hơn, vì thiết kế cần phải được điều chỉnh.

Các lỗi trong yêu cầu số 4 xuất hiện khi định nghĩa các yêu cầu 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ị loại bởi khách hàng hoặc người dùng cuối, dẫn đến chi phí phát hiện lỗi cao Thực tế cho thấy, các lỗi thường phát sinh từ bước tìm hiểu yêu cầu và thiết kế, chiếm đến một nửa tổng số lỗi trong các dự án, theo đánh giá hàng ngàn dự án.

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

Khi xem xét ảnh hưởng của các hỏng hóc do lỗi, cần đánh giá tác động của việc phát hiện và sửa chữa những lỗi này Chi phí cho việc tìm và khắc phục lỗi được tính dựa trên vòng đời của chúng Ví dụ, nếu bạn sửa một lỗ hổng nhỏ trên ống tay áo ngay bây giờ, việc này sẽ dễ dàng hơn rất nhiều so với việc để nó kéo dài, khi đó hỏng hóc sẽ trở nên nghiêm trọng hơn và cần nhiều công sức hơn để khắc phục.

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

Các thành phần của cấu phần

Mỗi cấu phần bao gồm một tập hợp các thuộc tính, phương thức và sự kiện, với mỗi cấu phần mang một tên và định danh riêng Thuộc tính đại diện cho các trạng thái hoặc đặc điểm của cấu phần, và mỗi thuộc tính được xác định bởi một kiểu cụ thể Phương thức thì mô tả hành vi và các dịch vụ mà cấu phần cung cấp.

Sự kiện mô tả hoạt động của cấu phần mà nó cài đặt Mỗi sự kiện cũng có một kiểu xác định

Hình vẽ dưới mô tả chi tiết cấu thành cấu phần phần mềm bao gồm:

 Hình chữ nhật: thể hiện các thuộc tính public

 Hình tròn: biểu thị các phương thức trong cấu phần

 Hình thoi: mô tả các sự kiện

Hình 5 Cấu trúc mô tả một cầu phần

M = {(v,a,t,i(p)) | v ∈ Tập hiển thị, a ∈ truy cập, t ∈ kiểu i ∈ tập định nghĩa, p ∈ tham số}

Công nghệ phần mềm cấu phần 2P × 2M × 2E được sử dụng để cập nhật hoặc tích hợp nhiều cấu phần, tạo ra một cấu phần mới hoặc ứng dụng Sự kết hợp này dựa trên các định nghĩa trong một hạ tầng cấu phần, nhằm tối ưu hóa hiệu suất và tính linh hoạt của hệ thống.

Các cấu trúc cây kế thừa các thành phần có thể được sử dụng để tạo ra những thành phần mới, dựa trên các đặc điểm của những thành phần đã được xây dựng trước.

UML và kiểm thử

Mô hình hóa trong sản xuất phần mềm nâng cao khả năng xác định yêu cầu, thiết kế rõ ràng và bảo trì hệ thống UML được áp dụng đa dạng trong từng giai đoạn của quy trình kiểm thử, bao gồm kiểm thử đơn vị, chức năng, hệ thống, hồi quy và giải pháp kiểm thử Bảng dưới đây trình bày sự hỗ trợ của UML trong các giai đoạn kiểm thử phần mềm.

Bảng 3: UML hỗ trợ các loại kiểm thử Loại kiểm thử Điều kiện áp dụng Loại lỗi Lược đồ UML Đơn vị Code

Sự đúng đắn, các điều kiện xử lý lỗi trước/ sau, tính bất biến.

Lược đồ lớp và trạng thái

Chức năng Chức năng hệ thống

Hành vi thuộc về chức năng và API, các vấn đề về tích hợp

Lược đồ tương tác và lớp

Hệ thống Các chuỗi vận hành

Khả năng làm việc, giải quyết xung đột, đồng bộ, khôi phục

Các lược đồ use case, hoạt động và tương tác

Hồi quy Các chức năng hệ thống

Hành vi không giống với mong đợi do sự thay đổi hoặc cập nhật chức năng mới

Giống với kiểm thử chức năng

Giải pháp Giao tiếp bên trong hệ thống

Các vấn đề vận hành bên trong

Các lược đồ use case và lươc đồ triển khai

Mặc dù UML có thể hỗ trợ quy trình kiểm thử, nhưng việc áp dụng nó cũng tiềm ẩn một số rủi ro Lược đồ UML chỉ thực sự hữu ích trong một số giai đoạn nhất định của quy trình kiểm thử Trước khi triển khai UML, cần xem xét kỹ lưỡng các vấn đề liên quan để đảm bảo tính hiệu quả và giảm thiểu rủi ro.

Mô hình hóa trong thiết kế và triển khai có thể được chuyển giao cho kiểm thử viên, nhưng điều này gặp khó khăn do yêu cầu kiến thức sâu rộng của họ để xây dựng hoặc sửa đổi các mô hình Thêm vào đó, các mô hình được tạo ra trong bước thiết kế thường không đầy đủ thông tin cần thiết cho quy trình kiểm thử tiếp theo.

Thứ hai, các mô hình phát triển thiếu tính chi tiết và các đặc trưng cần có để xây dựng tình huống áp dụng vào kiểm thử

Có 4 mức kiểm thử ta cần quan tâm đến khi thực hiện quy trình kiểm thử, đó là[12]:

Kiểm thử mức đơn vị

Kiểm thử mức đơn vị là quá trình kiểm tra tính chính xác của từng đơn vị chức năng riêng lẻ, tập trung vào các ngôn ngữ, chức năng hoặc thủ tục ở mức nhỏ nhất Các dạng kiểm thử đơn vị đóng vai trò quan trọng trong việc xây dựng nền tảng cho các hoạt động kiểm thử ở mức cao hơn, như việc vận hành các đơn vị tích hợp để đáp ứng yêu cầu thực thi chức năng cụ thể.

Kiểm thử mức tích hợp

Kiểm thử tích hợp phần mềm là quá trình kiểm tra sự tương tác giữa các đơn vị hoặc cấu phần phần mềm khi chúng được kết nối với nhau Trong khi kiểm thử mức đơn vị chỉ tập trung vào các cấu phần riêng lẻ, kiểm thử tích hợp chú trọng vào việc xác định các lỗi có thể phát sinh khi các đơn vị tương tác, chẳng hạn như các thông báo pop-up chỉ xuất hiện sau khi tích hợp Do đó, kiểm thử tích hợp đóng vai trò quan trọng trong quy trình kiểm thử, giúp đảm bảo rằng các cấu phần hoạt động hiệu quả khi kết hợp với nhau.

Kiểm thử mức hệ thống

Khi thực hiện kiểm thử mức hệ thống, một số cách tiếp cận đáng chú ý được đề xuất Briand và Labiche đã giới thiệu một phương pháp sinh ra các tình huống kiểm thử bằng cách sử dụng các lược đồ use case, lược đồ hoạt động và lược đồ tuần tự Phương pháp này giúp tạo ra các tình huống kiểm thử hiệu quả và có hệ thống.

Kiểm thử mức độ phù hợp

Kiểm thử phần mềm nhằm để thiết lập đầy đủ các yêu cầu đặc tả, xem xét mức độ phù hợp của phần mềm

Mô hình hóa đóng vai trò quan trọng trong từng giai đoạn của quy trình kiểm thử, giúp xây dựng các tình huống kiểm thử hiệu quả Việc áp dụng mô hình hóa cung cấp ý tưởng cơ bản về kiểm thử và phát triển môi trường kiểm thử Mỗi ca kiểm thử cần có sự xác định rõ ràng hoặc ít nhất là một mô tả, tài liệu minh chứng về những gì cần kiểm thử Kiểm thử không có sự xác định sẽ trở nên vô nghĩa, ngay cả kiểm thử hộp trắng cũng chỉ tập trung vào cấu trúc code dựa trên các xác định cụ thể.

Kiểm thử hệ thống được thực hiện thông qua một vector đầu vào, nơi các sự kiện được kích hoạt kết hợp với các tham số Các tham số này đóng vai trò quan trọng trong việc xây dựng các tình huống kiểm thử Đối với mỗi yếu tố đầu vào, chúng ta áp dụng lược đồ tương tác trong mô hình thiết kế để mô tả cách hệ thống phản ứng với các sự kiện cụ thể.

Khi thực hiện sửa lỗi ảnh hưởng đến luồng kiểm thử hoặc các thành phần đang được kiểm thử, các hoạt động sẽ được lặp lại để đảm bảo tính chính xác và hiệu quả trong quy trình kiểm thử.

Hình 6.Quy trình kiểm thử cấu phần trong hệ thống

Lập kế hoạch kiểm thử cấu phần Đặc tả tình huống kiểm thử cấu phần

Thực hiện kiểm thử trên cấu phần

Ghi nhận kết quả kiểm thử cấu phần

Kiểm tra toàn diện cấu phần

Trong hoạt đông kiểm thử sử dụng UML ta cần có sự phân biệt như sau:

Kiểm thử dựa trên mô hình - Điều này liên quan đến việc lấy thông tin từ mô hình UML

Mô hình kiểm thử - Tập trung vào cách để mô hình hóa cấu trúc kiểm thử và hành vi kiểm thử với UML a Kiểm thử dựa trên mô hình [4]

UML là một ngôn ngữ ký hiệu quan trọng trong việc mô tả và kiểm thử, trong đó kiểm thử là việc áp dụng các khái niệm từ đặc tả Một tình huống kiểm thử cho một cấu phần bao gồm các phép toán gọi trên đối tượng kiểm thử, các điều kiện trước để xác định ràng buộc đầu vào và trạng thái khởi tạo, cùng với các điều kiện sau để xác định trạng thái cuối sau khi kiểm thử Việc ánh xạ các cấu phần tới các tình huống kiểm thử được thực hiện một cách chính xác, và hoạt động xác thực trong kiểm thử giúp xác định thành công hay thất bại của tình huống kiểm thử Mặc dù khái niệm tình huống kiểm thử có phần phức tạp, hồ sơ kiểm thử UML cung cấp định nghĩa đầy đủ Như vậy, UML cung cấp mọi thông tin cần thiết để thực hiện kiểm thử và xây dựng tình huống kiểm thử, bao gồm cả việc định nghĩa các tập kiểm thử ứng dụng.

Hình 7 Lược đồ biểu diễn cấu trúc một ca kiểm thử

Tình huống kiểm thử Điều kiện trước Thao tác Điều kiện sau

Tham số đầu vào Tham số Tham số đầu ra

Ràng buộc Ràng buộc Định nghĩa Định nghĩa

Ví dụ: Trong hệ thống quản lý giao dịch thẻ ATM sẽ có các use case tham gia như sau:

Hình 8 Lược đồ biểu diễn các use case quản lý giao dịch ATM

Rút tiền từ tài khoản

Gửi tiền vào tài khoản

Kiểm tra tài khoản khách hàng

Kiểm tra loại thẻ giao dịch

Kiểm tra số dư tài khoản

Cập nhật tài khoản khách hàng ôusesằ ôusesằ ôusesằ Đăng nhập hệ thống ôextendsằ

Với từng tình huống cụ thể (tình huống rút tiền từ tài khoản ATM của khách hàng), cấu trúc mỗi tình huống được thể hiện như bảng dưới đây:

Mô tả Người dùng thực hiện giao dịch rút tiền từ tài khoản cá nhân

Thao tác Người dùng nhập số tiền cần rút khỏi tài khoản Điều kiện trước Hệ thống chấp nhận thẻ giao dịch của khách

Tài khoản đăng nhập của người dùng đã được xác thực Nếu điều kiện thành công, giao dịch rút tiền sẽ được thực hiện thành công, và hệ thống sẽ tự động trừ tiền từ tài khoản của khách hàng.

Nếu không thành công: Hệ thống thông báo tới khách hàng nguyên nhân thực hiện giao dịch không thành công

Tham số đầu vào Tài khoản chủ thẻ ATM

Tham số thực hiện giao dịch

Số tiền khách tực hiện giao dịch

Tham số đầu ra là số tiền giao dịch được cập nhật trong hệ thống sau mỗi giao dịch Mô hình kiểm thử bao gồm tập hợp các tình huống kiểm thử nhằm biểu diễn quá trình thực thi của phần mềm.

Bất kỳ phần mềm nào khi thực hiện chức năng thông thường đều phải dựa trên đặc tả UML, một ngôn ngữ ký hiệu đồ họa, tập trung vào đặc tả phần mềm kiểm thử trong ứng dụng Việc áp dụng ngôn ngữ ký hiệu đặc tả vào kiểm thử giúp nhận diện sự khác biệt giữa phát triển phần mềm thông qua mô hình hóa và phát triển phần mềm tự do.

UML cung cấp khung kiểm thử cần thiết cho các thành phần và đối tượng trong ứng dụng, với các khái niệm quan trọng được trình bày trong hồ sơ kiểm thử UML Hồ sơ này mở rộng mô hình siêu dữ liệu UML, đưa ra phương pháp và khái niệm kiểm thử Các lược đồ UML mô tả cách thực thi, hoạt động và nhận dạng hệ thống, đảm bảo mô hình UML phản ánh đầy đủ và chính xác hệ thống Hồ sơ kiểm thử mở rộng siêu mô hình UML với các khung và khái niệm kiểm thử cần thiết.

UML có thể mô tả mọi khía cạnh của hệ thống máy tính, và kiểm thử dựa trên các tài liệu đặc tả chức năng Kiểm thử xác thực việc cài đặt hệ thống có tuân thủ đúng các đặc tả Các mô hình ở mức trừu tượng cho phép chuyển đổi thành mã cụ thể, với sự khác biệt chính là mức độ cụ thể hóa của các mô hình Điều này dẫn đến việc xây dựng các tình huống kiểm thử cụ thể từ các đặc tả trừu tượng Kiểm thử dựa trên mô hình và các ca kiểm thử cụ thể được lấy từ lược đồ UML, với các lược đồ mức cao tạo ra tình huống kiểm thử ở mức cao, trong khi lược đồ mức thấp hướng đến các tình huống cụ thể hơn Tương lai có thể mở rộng tự động hóa kiểm thử từ các mô hình thông qua công cụ tích hợp Kiểm thử dựa trên mô hình và mô hình hóa kiểm thử là các hoạt động hỗ trợ lẫn nhau, với kiểm thử thực chất là công việc phát triển và thực thi phần mềm.

Kiểm thử phần mềm trên cơ sở cấu phần

Khi kiểm thử hệ thống phần mềm dựa trên cấu phần, giả định rằng mỗi cấu phần đã được kiểm thử đầy đủ là rất quan trọng Để xây dựng một hệ thống thành công, cần đảm bảo độ tin cậy và tính chính xác trong việc tương tác giữa các cấu phần Các cấu phần trong hệ thống có thể tương tác trực tiếp hoặc gián tiếp với nhau.

Dựa trên ý tưởng phát triển sản phẩm phần mềm mới bằng cách sử dụng các cấu phần có sẵn hoặc tái sử dụng, chúng ta có thể đạt được hiệu quả đầu tư cao hơn so với phương pháp phát triển phần mềm truyền thống Việc áp dụng các cấu phần tái sử dụng không chỉ tiết kiệm thời gian mà còn tối ưu hóa chi phí, mang lại giá trị lớn hơn cho dự án.

Trong hệ thống phần mềm cấu phần, chất lượng của hệ thống phụ thuộc vào chất lượng của từng cấu phần Cấu phần có lỗi sẽ ảnh hưởng tiêu cực đến toàn bộ hệ thống Do đó, việc xác thực và kiểm soát chất lượng cấu phần là trách nhiệm của cả nhà cung cấp và người dùng Để đảm bảo chất lượng, người dùng cần thực hiện các quy trình cụ thể nhằm đánh giá, xác thực và chấp nhận các cấu phần trước khi tích hợp vào hệ thống.

Một trong những cách tiếp cận đầu tiên trong kiểm thử cấu phần là phân chia theo nhà sản xuất, người dùng và nhà cung ứng, vì mỗi bên có những hiểu biết và tầm nhìn khác nhau về cấu phần Kiểm thử cấu phần từ nhà sản xuất rất phức tạp, đặc biệt với những cấu phần có khả năng tái sử dụng cao, đòi hỏi phải thực hiện trong bối cảnh độc lập Vấn đề chính của người dùng cấu phần là kiểm thử mã nguồn trong hệ thống, vì các kỹ thuật kiểm thử truyền thống thường cần mã nguồn của phần mềm Khi mã nguồn có sẵn, các cấu phần và ứng dụng có thể sử dụng ngôn ngữ phát triển khác nhau, gây khó khăn trong việc xác định chính xác các chức năng cấu phần được sử dụng Cuối cùng, việc đáp ứng các tiêu chí tuyệt đối trước khi kiểm thử là một thách thức lớn.

Trong công nghệ phần mềm dựa trên cấu phần (CBSE), việc kiểm thử các cấu phần phần mềm là trách nhiệm của cả nhà cung cấp và người dùng Kiểm thử cấu phần bao gồm hai loại chính: kiểm thử hoạt động và kiểm thử hiệu suất.

Kiểm thử cấu phần hướng – nhà cung ứng là một giai đoạn quan trọng trong quy trình phát triển cấu phần Quy trình này bao gồm các hoạt động kiểm thử do nhà cung ứng thực hiện nhằm xác thực cấu phần dựa trên các đặc tả đã được định nghĩa.

Kiểm thử cấu phần hướng người dùng là một bước quan trọng trong quy trình phát triển phần mềm, liên quan đến việc xác thực các cấu phần được tích hợp vào dự án ứng dụng Quá trình này bao gồm các hoạt động kiểm thử nhằm đảm bảo các đặc tả chức năng, giao diện và sự thực thi của cấu phần Ngoài ra, các cấu phần được sử dụng lại cũng cần được xác thực trong môi trường vận hành để đảm bảo chúng đáp ứng đúng ngữ cảnh đã đề ra.

Kiểm thử cấu phần hướng – nhà cung ứng: nhằm mục đích là trả lời các câu hỏi cho các đối tượng phát triển cấu phần:

 Cấu phần được xây dựng trên cơ sở đặc tả đưa ra có đảm bảo chất lượng không?

 Cấu phần được xây dựng có dựa trên các chuẩn đặc tả và mô hình cấu phần đưa ra hay không?

Nhà cung ứng sẽ kiểm tra sự tuân thủ các chức năng trong cấu phần theo đặc tả đã có, xem xét trên cơ sở logic, dữ liệu và cấu trúc chương trình để đảm bảo tuân thủ thuật toán Mục tiêu của việc kiểm thử không chỉ tập trung vào các dịch vụ riêng lẻ mà còn liên kết các dịch vụ trong cấu phần Nhà cung ứng hướng tới việc tạo ra sản phẩm chất lượng cao và có thể sử dụng lại Kiểm thử cấu phần có ba mục tiêu chính: phát hiện lỗi trong phạm vi đặc tả, xác thực các giao diện, chức năng, hành vi và hiệu năng, cũng như kiểm tra khả năng sử dụng lại, đóng gói và triển khai cấu phần trong môi trường đã định nghĩa.

Kiểm thử cấu phần hướng - người dùng: được thực hiện để trả lời các câu hỏi cho người dùng cấu phần:

 Chúng ta có lựa chọn và triển khai cấu phần có sẵn vào trong hệ thống không?

 Chúng ta có đang sử dụng lại một cấu phần đúng trong một hệ thống?

 Chúng ta có đang thực hiện tích hợp hoặc cập nhật một cấu phần đúng cho dự án?

Người dùng cấu phần sẽ đánh giá tính phù hợp của mô-đun với nền tảng ứng dụng dựa trên cấu phần kết hợp Việc xem xét này tương tự như đánh giá đối tượng hộp đen Mục tiêu của người dùng là tích hợp cấu phần có sẵn vào khung cấu phần và đánh giá sự cộng tác theo vai trò mà nhà sản xuất cung cấp thông qua kiểm thử Kiểm thử nhằm xác định khả năng tương thích của các cấu phần, bao gồm việc kết hợp các thành phần phát triển từ bên thứ ba và hiển thị các tương tác giữa các cấu phần.

Kiểm thử cấu phần hướng người dùng là quy trình xác thực và kiểm tra chất lượng của các cấu phần phần mềm trong hệ thống Mục tiêu chính của kiểm thử này bao gồm xác thực chức năng và hiệu suất của các cấu phần sử dụng lại, đảm bảo chúng đáp ứng đầy đủ yêu cầu dự án và toàn hệ thống Ngoài ra, kiểm thử cũng nhằm xác nhận khả năng sử dụng lại và triển khai các cấu phần trong môi trường vận hành cụ thể, cũng như kiểm tra chất lượng của các tùy biến cấu phần dựa trên cấu phần sử dụng lại.

Ba loại cấu phần được sử dụng trong dự án phát triển phần mềm trên cơ sở cấu phần:

 Các cấu phần được sử dụng lại hoàn toàn

 Các cấu phần được lắp ghép và cập nhật

 Các cấu phần được phát triển mới

Kiểm thử cấu phần phần mềm đem lại hiệu quả kinh tế và chất lượng sản phẩm trong sản xuất phần mềm là điều khẳng định chắc chắn

Chất lượng chương trình phát triển phụ thuộc vào các cấu phần và hiệu quả của việc kiểm thử từng đơn vị, kiểm thử tích hợp và kiểm thử hệ thống Trong quy trình kiểm thử, cán bộ kiểm thử phải đối mặt với nhiều khó khăn và thách thức.

Kiểm thử đơn vị các cấu phần phần mềm gặp nhiều khó khăn, bao gồm việc xác định loại kiểm thử phù hợp và thời gian mà nhà cung cấp cần thực hiện Ngoài ra, việc lựa chọn kỹ thuật để xây dựng các tình huống kiểm thử cũng rất quan trọng, cùng với thời điểm thích hợp để đưa các cấu phần vào vận hành.

 Tập các tình huống kiểm thử các cấu phần phần mềm được xây dựng là Add-hoc

 Kiểm thử thỏa đáng các cấu phần

 Khả năng kiểm thử các cấu phần tái sử dụng kém

 Tăng thêm chi phí vào việc kiểm thử các cấu phần tích hợp

 Việc quản lý tập các tình huống kiểm thử tích hợp các cấu phần là ad- hoc

Việc tích hợp các cấu phần gặp nhiều khó khăn, làm giảm khả năng điều khiển và kiểm tra hệ thống Điều này dẫn đến việc khả năng truy xuất đến các lời gọi trở nên yếu, gây ra những tiếp cận yêu cầu kém hiệu quả.

 Khó định dạng các bộ kiểm thử tích hợp dựa trên bộ kiểm thử cấu phần

 Chi phí xây dựng môi trường tích hợp là cao

 Thiếu mô hình kiểm thử tích hợp cấu phần ứng với tiêu chuẩn kiểm thử

Khó khăn trong kiểm thử hệ thống phần mềm cấu phần xuất phát từ việc các cấu phần được phát triển trong ngữ cảnh cụ thể của nhà cung ứng, nhưng lại được sử dụng lại trong các ngữ cảnh phát triển khác nhau.

 Khó kiểm soát được các hành vi hệ thống: tách biệt lỗi, xử lý, debug lỗi một cách độc lập

 Chi phí cao khi thực hiện kiểm thử hiệu năng và điều khiển hệ thống

 Yếu trong việc điều phối và xác thực nguồn lực hệ thống

Sự khác biệt chính giữa kiểm thử truyền thống và kiểm thử dựa trên cấu phần nằm ở cách nhìn nhận hệ thống và mối quan hệ giữa nhà cung ứng và người dùng Kiểm thử phần mềm truyền thống xác thực các hệ thống phần mềm khác với kiểm thử phần mềm phát triển dựa trên cấu phần Khi thực hiện kiểm thử tích hợp các cấu phần, các kỹ thuật từ kiểm thử phần mềm truyền thống vẫn được áp dụng, đồng thời cho phép thực hiện kiểm thử ở cả mức hộp đen và hộp trắng trong quá trình tích hợp các cấu phần.

Các kỹ thuật có thể áp dụng khi tiến hành kiểm thử hệ thống phần mềm như: Kiểm thử chức năng

Kiểm thử luồng nghiệp vụ

Các khía cạnh kiểm thử

Khái niệm quy trình kiểm thử có thể được chia ra thành các hoạt động dưới đây [16]:

 Xây dựng lược đồ giao tiếp UML

 Định nghĩa các lược đồ trạng thái triển khai từ lược đồ giao tiếp

Để tạo đường dẫn kiểm thử hiệu quả, cần xác định các tiêu chí và nhánh kiểm thử cụ thể Quá trình này bắt đầu từ việc thực hiện mô hình kiểm thử, trong đó các trạng thái trước và sau khi thực hiện mỗi nhánh sẽ được ghi lại để đảm bảo tính chính xác và hiệu quả của kiểm thử.

So sánh trạng thái của đối tượng sau khi thực hiện kiểm thử với trạng thái mong muốn là bước quan trọng trong quy trình kiểm thử Tình huống kiểm thử được đánh giá để xác định xem đối tượng đạt yêu cầu thành công hay không.

Khi áp dụng quy trình kiểm thử vào hệ thống phần mềm xây dựng, ta cần quan tâm đến các khía cạnh sau:

3.3.1 Khía cạnh cấu trúc của kiểm thử

Hồ sơ kiểm thử UML định nghĩa kiến trúc kiểm thử, bao gồm các khía cạnh cấu trúc kiểm thử trong UML Kiến trúc này chứa các thành phần kiểm thử, bối cảnh kiểm thử và mối liên hệ với hệ thống đặc tả từ góc độ kiểm thử (SUT), hệ thống con hoặc phần mềm được kiểm thử Ngữ cảnh kiểm thử thể hiện tập hợp các tình huống kiểm thử kết hợp với cấu hình kiểm thử để áp dụng vào hệ thống Cấu hình kiểm thử bao gồm các thành phần và mô tả cách chúng kết hợp với phần đã kiểm thử Một thành phần đặc biệt trong kiến trúc này là arbiter, có nhiệm vụ đánh giá kết quả kiểm thử và đưa ra kết luận về tình huống kiểm thử là thành công, chưa có kết luận, thất bại hoặc lỗi.

*)Arbiter: Là cấu phần kiểm thử rất đặc biệt chịu trách nhiệm đánh giá, theo dõi một tình huống kiểm thử có kết quả ngược lại với mong đợi

Hình 9 Mô hình biểu diễn cấu trúc của hồ sơ kiểm thử

Ngữ cảnh Cấu hình Cấu phần

Hệ thống dưới góc độ kiểm thử (SUT) Tình huống kiểm thử

3.3.2 Khía cạnh hành vi của kiểm thử

Hành vi kiểm thử được xác định qua các khái niệm trong hồ sơ kiểm thử, với tình huống kiểm thử chắc chắn là khái niệm quan trọng nhất Tình huống này đặc tả nội dung kiểm thử dựa trên điều kiện và dữ liệu đầu vào, đồng thời được kết hợp với mô tả chung nhằm mục đích kiểm thử Mô tả này thể hiện mục tiêu kiểm thử và xác định rõ ràng tình huống kiểm thử Trong quá trình thực thi, kết quả của từng tình huống được ghi lại và hiển thị qua các thông điệp trao đổi giữa cấu phần kiểm thử và hệ thống Cuối cùng, sau khi thực hiện, mỗi tình huống kiểm thử sẽ có kết quả đánh giá, cho biết tình huống đó thành công hay thất bại Hình ảnh dưới đây tổng hợp các khái niệm liên quan đến tình huống kiểm thử.

Hình 10 Các khái niệm liên quan đến tình huống kiểm thử

Đánh giá

Thành công Thất bại Lỗi Chưa có kết luận

Mục tiêu kiểm thử Tình huống kiểm thử

Hành vi trong một tình huống kiểm thử bao gồm việc tác nhân kiểm thử gửi dữ liệu đến hệ thống và quan sát phản hồi từ hệ thống Việc đánh giá phản ứng của hệ thống được thực hiện thông qua hành động xác thực, với đầu ra xác định tình huống kiểm thử Một đánh giá thành công cho thấy hệ thống đáp ứng đúng kết quả mong đợi, trong khi đánh giá thất bại chỉ ra rằng phản ứng của hệ thống khác với mong đợi của người dùng Đánh giá không xác định có nghĩa là không thể xác định thành công hay thất bại, trong khi đánh giá lỗi chỉ ra sự cố trong hệ thống kiểm thử Các hành vi kiểm thử được tổng kết trong mô tả dưới đây.

Hình 11 Các khái niệm liên quan đến hành vi kiểm thử

Đánh giá

Thành công Thất bại Lỗi Chưa có kết luận

Tác nhân kiểm thử Hành vi kiểm thử Hành động xác thực

Các tác động và quan sát từ hệ thống phản ánh dữ liệu trong tình huống kiểm thử, được gọi là tham số kiểm thử Tham số này có thể bao gồm các đối số, phân lớp dữ liệu hoặc quy tắc code Đối số là giá trị vật lý cụ thể, trong khi lớp dữ liệu là giá trị logic, như lớp tương đương của các đối số đúng Quy tắc code là yếu tố cần thiết khi giao diện hệ thống yêu cầu mã hóa đặc biệt, như XML, và cần được xem xét trong quá trình kiểm thử Hình ảnh dưới đây minh họa tổng quan về các kết hợp dữ liệu trong hồ sơ kiểm thử.

Hình 12 Các khái niệm dữ liệu trong hồ sơ kiểm thử

Tham số kiểm thử Đối số Phân lớp dữ liệu

Áp dụng UML vào kiểm thử là một phương pháp hoàn toàn phù hợp, vì UML có khả năng đặc tả mọi khía cạnh của hệ thống Nó cho phép mô phỏng hệ thống, thiết kế giao diện người dùng mong muốn và xác định các yêu cầu mà hệ thống cần đáp ứng Kiểm thử sẽ xác minh xem việc cài đặt của hệ thống có tuân thủ các đặc tả đã được định nghĩa hay không Hơn nữa, UML có thể được sử dụng để mô hình hóa và đặc tả khung kiểm thử hệ thống một cách hiệu quả.

Mô hình kiểm thử trong phần mềm cấu phần [5]

Mô hình kiểm thử thể hiện cách để kiểm thử phần mềm trên cơ sở cấu phần

Sự thực thi kỹ thuật mô hình hóa đối mặt với thách thức trong việc đảm bảo hiệu quả kiểm thử khi mã nguồn của các cấu phần không có sẵn Trong trường hợp này, mặc dù có thể đặc tả các giao diện và sự kiện, nhưng thông tin cần thiết cho các quan hệ như phụ thuộc bối cảnh và nội dung lại không được cung cấp Những yếu tố này rất quan trọng để phát hiện lỗi khi tích hợp hai cấu phần Để giải quyết vấn đề này, chúng ta sử dụng ngôn ngữ UML để nắm bắt các mối quan hệ giữa các cấu phần.

Hiện nay, công nghệ phần mềm đang phát triển nhanh chóng với nhiều mô hình và kỹ thuật mới Sự đa dạng của các mô hình cấu phần đã dẫn đến sự gia tăng số lượng cấu phần sản xuất Để đảm bảo quy trình kiểm thử diễn ra hiệu quả và đáp ứng yêu cầu, cũng như duy trì phần mềm dựa trên cấu phần, cần tuân thủ hai dạng thể hiện các đặc tính không phụ thuộc vào mô hình và công nghệ của phần mềm.

Mô hình tương tác: Mô tả các cấu phần tương tác với nhau trong một hệ thống phần mềm cấu phần

Mô hình hành vi: Mô tả cấu trúc bên trong cấu phần và hành vi tương ứng

Mô hình hành vi cung cấp thông tin quan trọng về cấu trúc điều khiển nội bộ, độ tin cậy của dữ liệu và hiệu suất thông tin.

Mô hình tương tác tập trung vào việc phân tích sự tương tác giữa các thành phần trong hệ thống nhằm phát hiện các khiếm khuyết vận hành, sự không tương thích và khả năng gây lỗi khác Trong hệ thống phần mềm cấu phần, mỗi cấu phần chỉ có thể giao tiếp với các cấu phần khác thông qua giao diện của nó Các lời gọi thực thi có thể diễn ra theo nhiều cách, bao gồm lời gọi trực tiếp qua giao diện, lời gọi đến ngoại lệ, hoặc thao tác của người dùng kích hoạt một sự kiện gọi đến giao diện Trước khi khám phá sâu hơn về mô hình tương lai, chúng ta cần làm rõ các định nghĩa về “Giao diện” và “Sự kiện”.

Giao diện là phương thức truy cập cơ bản để kích hoạt các thành phần trong hệ thống Vì vậy, trong quá trình kiểm thử tích hợp và kiểm thử hệ thống, mỗi giao diện cần được kiểm thử ít nhất một lần trong môi trường tích hợp.

Mỗi giao diện trong phần mềm cần được kiểm thử ít nhất một lần sau khi triển khai, tương tự như tiêu chuẩn kiểm thử truyền thống yêu cầu mỗi hàm hoặc thủ tục phải được kiểm thử ít nhất một lần Tuy nhiên, cùng một giao diện có thể cho ra kết quả khác nhau khi được gọi trong các ngữ cảnh khác nhau Để quan sát đầy đủ hành vi của từng giao diện trong suốt quá trình chạy, mỗi lời gọi giao diện và sự kiện cần phải được kiểm thử ít nhất một lần Các sự kiện thường được phân loại thành ba loại chính: sự kiện lời gọi giao diện thông thường, sự kiện ngoại lệ và sự kiện thao tác người dùng.

Tương tác trực tiếp giữa các cấu phần trong kiến trúc cần được quản lý theo tài khoản Kiến trúc tương tác tổng thể được kiểm thử thông qua hai phương pháp: kiểm tra các quan hệ cấu trúc điều khiển và đánh giá các tương tác dữ liệu.

Trong mô hình tương tác, việc nhận diện các phần tử cơ bản là rất quan trọng, đặc biệt khi làm việc với các cấu phần thương mại (COTS) mà mã nguồn không có sẵn Để đặc tả hành vi của các cấu phần này, cần một mô hình hành vi để xác định các giao diện, sự kiện và cấu trúc dữ liệu Ngay cả khi mã nguồn có sẵn, mô hình hành vi vẫn có thể giúp trừu tượng hóa và thể hiện các đặc điểm của cấu phần hiệu quả hơn Hơn nữa, mô hình này cung cấp một định nghĩa thống nhất để đánh giá kiểm thử và các thuộc tính chất lượng khác Do đó, để phát triển một mô hình hành vi, cần một công cụ đáp ứng các khả năng cụ thể.

 Khả năng để đặc tả các hành vi bên trong cấu phần một cách hiệu quả và chính xác

Được chấp nhận rộng rãi có nghĩa là khi các thành phần từ các nhà cung cấp khác nhau được kết hợp, nguồn lực cần thiết để thực hiện tích hợp sẽ được quản lý ở mức tối thiểu.

Dễ đạt được có nghĩa là khi nhà cung cấp cấu phần chuẩn bị mô hình hành vi, các hành vi này cần được quản lý ở mức tối thiểu.

Các cấu phần của hệ thống dễ dàng được thêm, xóa hoặc nâng cấp, cho phép cập nhật thường xuyên các mô hình cấu phần Công cụ này cũng có khả năng nâng cấp một cách linh hoạt để phản ánh những thay đổi cần thiết.

UML là ngôn ngữ đặc tả giúp xây dựng, trừu tượng hóa và tài liệu hóa các giả định của hệ thống phần mềm chuyên sâu, đáp ứng chính xác vai trò đã được xác định từ sớm.

Kiểm thử giao diện và sự kiện cần đảm bảo rằng mọi tương tác giữa hai cấu phần client và server được thực thi Tuy nhiên, việc thực thi hệ thống phần mềm dựa trên cấu phần không chỉ là tương tác trực tiếp giữa hai cấu phần, mà còn thể hiện các mối quan hệ giữa các tương tác đã được ghi nhận Để hiểu rõ các quan hệ bên trong các tương tác, cần định nghĩa một cấu trúc điều khiển cho hệ thống Cấu trúc điều khiển này có thể được xem như một quan hệ phụ thuộc điều khiển trong phần mềm truyền thống Rõ ràng, hai phần tử khác nhau trong cấu trúc điều khiển, giao diện và sự kiện, dẫn đến bốn loại cấu trúc điều khiển khác nhau.

Cấu trúc giao diện tương tự như việc gọi thủ tục thông thường, trong đó một giao diện thực thi việc gọi đến một giao diện khác.

Cấu trúc giao diện liên quan đến các sự kiện xảy ra trong quá trình thực thi giao diện Trong quá trình này, các trường hợp ngoại lệ có thể phát sinh, phản ánh những hành vi không mong đợi từ hệ thống hoặc do người dùng xác định.

UML trong pha kiểm thử tích hợp

Để phát triển một hệ thống phần mềm dựa trên cấu phần, việc kiểm thử từng cấu phần riêng lẻ là rất quan trọng Khả năng gắn kết của các cấu phần cần được xem xét vì chúng có thể được phát triển bởi các nhóm khác nhau, sử dụng các ngôn ngữ lập trình và nền tảng hệ điều hành khác nhau Do đó, kiểm thử tích hợp là cần thiết để đảm bảo sự giao tiếp chính xác giữa các cấu phần Chuẩn IEEE đã định nghĩa rõ ràng về giao tiếp giữa các cấu phần này.

Kiểm thử trong đó các cấu phần phần mềm, cấu phần phần cứng hoặc cả hai được kết hợp Kiểm thử để đánh giá sự tương tác giữa chúng

Khi phát triển phần mềm theo cấu phần, việc kiểm thử từng phần riêng rẽ là cần thiết Tuy nhiên, các vấn đề có thể phát sinh trong quá trình tích hợp các cấu phần này Để xác định các vấn đề, cần thực hiện kiểm thử tích hợp một cách hiệu quả Mô hình kiểm thử giúp phát hiện khiếm khuyết trong kiểm thử mức đơn vị, với các khiếm khuyết liên quan đến sự tương tác giữa các cấu phần Những khiếm khuyết này có thể được phân loại thành hai nhóm: khiếm khuyết bên trong cấu phần và khiếm khuyết không liên quan đến ngôn ngữ lập trình, cũng như các khiếm khuyết xuất hiện khi người dùng thao tác với hệ thống Các khiếm khuyết được phát hiện qua kiểm thử đơn vị và kiểm thử tích hợp, và được phân loại theo các dạng khiếm khuyết cơ bản.

Dạng 1: Các khiếm khuyết trong cấu phần

Khiếm khuyết trong hệ thống thường được phát hiện khi các thành phần tương tác với nhau, đặc biệt liên quan đến ngôn ngữ lập trình Khi một phần tử cấu thành được kết hợp với các phần tử khác, nó có thể tạo ra khiếm khuyết bên trong cấu phần Ví dụ, trong đoạn mã, sau khi thêm i=0 vào hàm I1 của cấu phần C1 và kiểm tra các hàm I1, I2, không phát hiện lỗi Tuy nhiên, khi triển khai các cấu phần C1, C2, C3 và I1 được gọi bởi I2, lỗi lại xảy ra trong cấu phần C3.

Nhiều khả năng gây khiếm khuyết trong hệ thống có thể được phân loại là khiếm khuyết trong cấu phần, như lỗi deadlock làm trì trệ hệ thống hoặc tác vụ rơi vào vòng lặp vô hạn (livelock) Mục tiêu chính của kiểm thử tích hợp là phát hiện những khiếm khuyết này trong hệ thống.

Dạng 2: Các khiếm khuyết trong thao tác (Interoperability)

Hệ thống xây dựng dựa trên cấu phần có thể gặp nhiều vấn đề như tính không đồng nhất, mã nguồn không khả dụng và khả năng sử dụng lại gây khó khăn trong thao tác Các lỗi thao tác được phân loại theo ba mức: hệ thống, ngôn ngữ lập trình và mức đặc tả Ở mức hệ thống, các cấu phần có thể được phát triển trên các hạ tầng khác nhau, dẫn đến tình trạng không tương thích hoàn toàn Chẳng hạn, sự không tương thích giữa các sản phẩm CORBA có thể ảnh hưởng đến khả năng tương tác giữa các cấu phần CORBA.

Các khiếm khuyết trong ngôn ngữ lập trình có thể dẫn đến lỗi do sự không tương thích giữa các cấu phần được viết bằng các ngôn ngữ khác nhau Chẳng hạn, Microsoft cung cấp hỗ trợ cho việc tích hợp các cấu phần này.

Khi lập trình viên sử dụng các ngôn ngữ lập trình như VC và VB, họ thường không gặp vấn đề khi thao tác với các số nguyên Tuy nhiên, sự không tương thích có thể xảy ra khi họ làm việc với các số thực Một trong những nguyên nhân chính dẫn đến sự không tương thích này là do các khiếm khuyết mức đặc tả Điều này xảy ra khi lập trình viên có những hiểu biết không đúng về đặc tả của ngôn ngữ lập trình, và sự thiếu hiểu biết này thể hiện theo nhiều cách khác nhau Loại lỗi này thường phát sinh khi truyền dữ liệu vào từ giao diện hoặc các mẫu tương tác cấu phần.

Dạng 3: Các khiếm khuyết căn bản và các khiếm khuyết khác

Kiểm thử truyền thống và các kỹ thuật bảo trì giúp phát hiện khiếm khuyết trong các cấu phần độc lập, được định nghĩa là khiếm khuyết căn bản Ngoài ra, còn có các khiếm khuyết khác liên quan đến đặc tả đầu vào và môi trường thực thi theo đặc tả.

3.5.1 Mô hình áp dụng cho kiểm thử tích hợp phần mềm cấu phần

Kiểm thử phần mềm tập trung vào tính hiệu quả thông qua mô hình kiểm thử mở rộng từ cách tiếp cận đồ họa Mô hình này định nghĩa các nhân tố kiểm thử có khả năng phát hiện các khiếm khuyết tích hợp, giúp nâng cao chất lượng phần mềm.

Các phần tử kiểm thử:

Trong quá trình kiểm thử tích hợp, mô hình kiểm thử tập trung vào việc phát hiện khiếm khuyết thông qua sự tương tác giữa các cấu phần trong hệ thống phần mềm Các cấu phần có thể tương tác trực tiếp qua lời gọi giao diện hoặc gián tiếp thông qua các sự kiện tuần tự Việc kiểm thử từng giao diện trong môi trường tích hợp là cần thiết, với yêu cầu mỗi giao diện phải được gọi ít nhất một lần trong quá trình kiểm thử Điều này tương tự như tiêu chí kiểm thử truyền thống, yêu cầu mỗi chức năng phải được kiểm thử ít nhất một lần Tuy nhiên, cùng một lời gọi giao diện trên các cấu phần khác nhau có thể cho ra kết quả khác nhau, do đó, mỗi lời gọi của các giao diện cần được kiểm thử ít nhất một lần để quan sát các hành vi có thể xảy ra Ngoài ra, các sự kiện không được kích hoạt qua giao diện cũng có thể ảnh hưởng đến các cấu phần và cũng cần được kiểm thử, do đó, mọi sự kiện trong hệ thống đều cần được kiểm thử.

Các mối quan hệ phụ thuộc ngữ cảnh

Kiểm thử giao diện và sự kiện đảm bảo tương tác giữa client và server Tuy nhiên, việc thực thi hệ thống phần mềm có thể dẫn đến kết quả không như mong đợi do sự tương tác giữa các cấu phần Để hiểu mối quan hệ giữa các sự kiện, ta định nghĩa quan hệ phụ thuộc bối cảnh giống như phụ thuộc luồng điều khiển trong phần mềm truyền thống Một sự kiện e2 có quan hệ phụ thuộc bối cảnh với sự kiện e1 nếu e1 tác động lên e2, trực tiếp hoặc gián tiếp Cần kiểm thử sự kiện e với tất cả các sự kiện có mối quan hệ phụ thuộc bối cảnh để quan sát ảnh hưởng lên đầu ra Quan hệ phụ thuộc bối cảnh cũng bao gồm các quan hệ cộng tác không trực tiếp giữa các giao diện và sự kiện, giúp phát hiện lỗi thao tác sai khi tương tác giữa các cấu phần khác nhau.

Các quan hệ phụ thuộc về nội dung ( content-dependence relationships)

Quan hệ phụ thuộc về nội dung giữa hai giao diện v1 và v2 thể hiện mối quan hệ dữ liệu giữa chúng, trong đó mỗi giao diện bao gồm một hoặc nhiều ký hiệu (signature) được gọi thông qua các lời gọi mô tả chức năng Khi một giao diện được gọi, các chức năng liên quan sẽ được thực thi để đáp ứng yêu cầu dịch vụ Mối quan hệ này có thể được nhận diện từ quan hệ phụ thuộc chức năng, đóng vai trò quan trọng trong kiểm thử lớp hướng đối tượng và kiểm thử hồi quy Cụ thể, một chức năng f2 phụ thuộc vào f1 nếu giá trị của biến trong f1 được sử dụng trong f2 Do đó, một giao diện v2 có quan hệ phụ thuộc nội dung với giao diện v1 khi v1 chứa lời gọi của f1, v2 chứa lời gọi của f2, và f2 phụ thuộc vào f1.

Tương tác giữa giao diện và sự kiện, cùng với các quan hệ phụ thuộc về nội dung, đóng vai trò quan trọng trong sự tương tác của hệ thống dựa trên cấu phần trong bối cảnh luồng điều khiển Phụ thuộc về nội dung (content-sensitive dependence) không chỉ giúp sinh ra các tình huống mà còn hỗ trợ trong việc phát hiện các khiếm khuyết.

Lược đồ tương tác cấu phần

Lược đồ tương tác cấu phần (CIG - Component Interaction Graph) mô tả các chuỗi tương tác giữa các cấu phần Các tương tác này có thể diễn ra trực tiếp hoặc gián tiếp; tương tác trực tiếp thông qua một sự kiện đơn, trong khi tương tác gián tiếp diễn ra qua nhiều sự kiện trong yêu cầu thực thi Quan hệ phụ thuộc dữ liệu trong các tương tác này sẽ mang lại các giá trị đầu ra khác nhau.

CIG được định nghĩa là CIG = (V, E), trong đó V bao gồm VI và VE, với VI là tập hợp các nút giao diện và VE là tập hợp các nút sự kiện E đại diện cho tập hợp các cạnh Lược đồ tương tác minh họa các phương pháp tiếp cận trực tiếp được áp dụng.

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

Sử dụng cấu phần Text trong Java

Swing cung cấp 6 loại cấu phần văn bản, đáp ứng hầu hết các yêu cầu phức tạp nhờ vào các lớp và giao diện Tất cả các cấu phần văn bản của Swing đều kế thừa từ các lớp cấp cao hơn, cụ thể là JTextComponent.

Hình 18 Cây cấu phần JtextComponent [7]

Dưới đây là một ứng dụng TextSamplerDemo sử dụng cấu phần có sẵn Swing text.

Hình 19 Ví dụ xây dựng trên nền javabean [7]

B1: Nhấn nút [Launch] để chạy chương trình TextSamplerDemo sử dụng Java™ Web Start

Nhập dữ liệu vào trường Text và nhấn Enter, sau đó thực hiện tương tự với trường mật khẩu Trường nhãn bên dưới sẽ được cập nhật ngay sau khi bạn nhấn Enter.

B3: Thử nhập các dữ liệu ngày đúng và sai vào trường định dạng dữ liệu là ngày

B4: Lựa chọn và chỉnh sửa nội dung trong khu vực văn bản và bảng văn bản Sử dụng các phím tắt Ctrl-X, Ctrl-C và Ctrl-V để thực hiện các thao tác cắt, sao chép và dán văn bản một cách hiệu quả.

B5: Thử sửa text trong editor pane, dữ liệu trường này không sửa được với lời gọi setEditable

B6: Xem text pane để thấy rõ ví dụ về cấu phần nhúng và các icon được nhúng

SwingText được tích hợp như một thành phần sẵn có, giúp phần mềm xây dựng sử dụng hiệu quả Thành phần này được phát triển dựa trên việc kế thừa và cải tiến những công nghệ đã tồn tại.

Việc kiểm thử được thực hiện thông qua việc nhập dữ liệu vào trường text và lưu trữ thông tin vào cơ sở dữ liệu Các lỗi có thể phát sinh sẽ được phát hiện khi tích hợp các thành phần text vào Java Tương tự, khi kết nối các thành phần có sẵn vào ứng dụng, chúng ta có thể kiểm tra khả năng phát sinh lỗi thông qua các tương tác giữa các thành phần và ứng dụng xây dựng.

Bài toán thực nghiệm dưới đây sẽ minh họa cụ thể hơn về việc sử dụng lại các cấu phần đã có sẵn trong quá trình phát triển phần mềm.

Bài toán ( Phát biểu)

Trong quá trình bán hàng, các đơn vị mong muốn kiểm soát doanh thu và hàng tồn kho của từng nhân viên Việc theo dõi hệ thống bán hàng tại các đơn vị cấp trên gặp nhiều khó khăn, do đó cần một phần mềm mới để đáp ứng các mục tiêu sau: quản lý quá trình xuất, nhập kho tại cửa hàng hoặc kho nhân viên; xác định lượng hàng xuất, nhập và tồn tại mỗi kho; và kiểm soát các mặt hàng tại kho cửa hàng hoặc kho nhân viên.

Khi có mặt hàng mới nhập về kho, thủ kho tại cửa hàng thực hiện nhập hàng về kho sau đó giao hàng đến các kho nhân viên

Mỗi nhân viên sở hữu một kho hàng riêng, nơi các giao dịch bán hàng diễn ra trực tiếp giữa nhân viên và khách hàng Sau khi hoàn tất giao dịch, hàng hóa sẽ được trừ trực tiếp từ kho của nhân viên.

Quy trình xây dựng tài liệu kiểm thử dựa trên mô hình UML

Phương pháp tổ chức chức năng hệ thống thông qua các Use cases mang lại sự hoàn chỉnh và hiểu biết tốt hơn cho các nhà phát triển yêu cầu người dùng Thay vì chỉ đánh đề mục các yêu cầu, Rational hỗ trợ tổ chức chúng theo một chuỗi hệ thống Điểm nổi bật của use cases là không chỉ mang tính hướng đối tượng mà còn thể hiện sự rõ ràng, giúp làm nổi bật các khía cạnh quan trọng trong quá trình phát triển.

 Use case có thể thể hiện các quy trình nghiệp vụ

 Use case cũng thể hiện dưới dạng mô tả các yêu cầu phần mềm

 Trong nguyên tắc quản lý dự án, use case được sử dụng như là cơ sở cho sự phát triển lặp lại kế hoạch

 Use case được nhận diện trong mô hình thiết kế như một nguyên tắc phân tích thiết kế

 Cuối cùng use case được tiến hành qua các chuỗi thử nghiệm và triển khai

Trong nguyên tắc phát triển, use case đóng vai trò quan trọng trong việc hướng dẫn người dùng và định nghĩa các đơn vị sản phẩm Để kiểm thử các yêu cầu trong hệ thống, nhân viên kiểm thử cần xây dựng tài liệu mô tả tình huống kiểm thử Các bước xây dựng tài liệu tình huống kiểm thử dựa trên mô hình use case có thể được thực hiện theo quy trình cụ thể.

1 Với mỗi use case, tạo đầy đủ các chuỗi use case scenario

2 Mỗi scenario, định nghĩa ít nhất một tình huống kiểm thử và các điều kiện để

“thực hiện” tình huống đó

3 Với mỗi tình huống, định nghĩa các bộ dữ liệu phục vụ kiểm thử.

Mô hình xây dựng use-case với bài toán thực tế

Hệ thống bán hàng được xây dựng dưới dạng các use case, và các tác nhân tham gia hệ thống như sau:

Hình 20 Mô hình use case mô tả bài toán phát biểu

Nhận hàng khách trả Nhập hàng

Nhập hàng - Hàng do nv trả

Xuất hàng - NV Trả hàng

Nhập hàng - NV nhập hàng

Xuất kho ôusesằ ôextendsằ ôusesằ ôextendsằ ôextendsằ ôusesằ ôextendsằ ôusesằ ôusesằ

Lập húa đơn ôusesằ ôusesằ

Xuất hàng đổi cho khách ôusesằ

4.4.1 Xây dựng luồng nghiệp vụ trên cơ sở cách tiếp cận mô hình cộng tác/tuần tự

Để mô tả nghiệp vụ bài toán, chúng ta sử dụng lược đồ cộng tác UML và biểu đồ tuần tự để thể hiện sự tương tác giữa các thành phần trong hệ thống Các thành phần tham gia bao gồm nhóm cấu phần phục vụ, bao gồm server components như giao dịch, kho, hóa đơn và quản lý giao dịch, cùng với client components.

Trước hết, ta thể hiện mô hình tương tác cấu phần hệ thống trên thông qua biểu đồ cộng tác của một mô hình giao dịch bán hàng

Hình 21 Mô hình cộng tác - bài toán thực tế

Lược đồ tuần tự mô tả tương tác giữa các cấu phần theo trình tự thời gian thực hiên như sau:

Hình 22 Mô hình tuần tự - trên bài toán thực tế

Kho Hóa đơn Giao dịch

Object4 Client component

Lược đồ trên mô tả các tương tác nghiệp vụ gồm:

W1: Gửi yêu cầu mua hàng W6: Yêu cầu lập hóa đơn W2: Kiểm tra lượng hàng đáp ứng trong kho

W7: Kiểm tra hóa đơn giao dịch trong kho

W3: Trừ lượng hàng trong kho cho giao dịch

W8: Trừ 1 hóa đơn sử dụng

W3A: Lượng hàng trong kho không đủ giao dịch

W8A: Không còn hóa đơn trong kho

Để thực hiện một giao dịch mua hàng của khách, các bước cần tuân theo theo thứ tự là: W1, W2, W3, W4 và W5 Sau khi ghi nhận giao dịch (W4), sẽ tiến hành lập hóa đơn (W9) và thông báo giao dịch thành công (W5) Cuối cùng, hệ thống sẽ gửi thông báo lập hóa đơn cho giao dịch (W10).

Biểu đồ trên minh họa chuỗi khả năng theo thứ tự thời gian, kết hợp với các thành phần khác Trong hình, W3, W3A và W8, W8A tập trung vào hai luồng đảo, xảy ra sau khi thông điệp W2 hoặc W7 được truyền qua đối tượng giao dịch.

Từ mô hình tương tác, chúng ta có thể mô tả chi tiết các chức năng trong hệ thống thông qua các usecase, thể hiện sự tương tác với nhau Dưới đây là quy trình làm việc tương ứng với từng usecase.

UC001 – Xem thông tin kho

Tên Usecase: Xem thông tin kho

 Cho phép người sử dụng xem được thông tin hàng trong kho của mình và kho cấp dưới

 Usecase được sử dụng trong một số usecase khác để kiểm soát lượng hàng trong kho mỗi khi xuất hoặc đề nghị xuất

Hệ thống Người sử dụng

Lấy thông tin kho Chọn mặt hàng

Hiển thị thông tin kho

1 NSD chọn kho cần xem thông tin kho từ danh mục kho

Khi sử dụng trong các usecase khác, thông tin này có thể được hệ thống điền tự động

Các thông tin kho trong danh mục kho gồm:

- Tên kho Mặc định kho được chọn là kho tại đơn vị của NSD

2 NSD chọn mặt hàng cần xem thông tin kho từ danh mục mặt hàng, có thể chọn toàn bộ các mặt hàng trong danh mục hàng

Danh mục mặt hàng gồm:

3 Hệ thống truy cập CSDL, lấy về thông tin về các mặt hàng đang có trong kho

4 Hệ thống hiển thị thông tin lấy được trên giao diện tương ứng với từng mặt hàng chọn:

Các thông tin kho hiển thị:

Số lượng thực tế là số lượng mặt hàng trong kho được phân loại theo từng loại mặt hàng và trạng thái đã được yêu cầu từ phòng bán hàng, nếu kho đó có phòng bán hàng.

Số lượng đáp ứng là tổng số mặt hàng có trong kho, được tính theo từng loại sản phẩm và trạng thái tồn kho sau khi đã trừ đi số lượng mà các phòng bán hàng yêu cầu, nếu kho đó có phòng bán hàng.

 Nhân viên thực hiện thuộc kho nào thì chỉ xem được thông tin tại kho đó

 Nhân viên thực hiện thuộc kho nào thì chỉ xem được thông tin các kho cấp dưới của kho đó

 Các thông tin về mặt hàng trong kho được lấy về:

- Số lượng trong kho theo mặt hàng và trạng thái,

- Số lượng mặt hàng trong kho theo mặt hàng và trạng thái đã được yêu cầu.từ phòng bán hàng (Nếu tại kho đó có phòng bán hàng)

Số lượng mặt hàng trong kho được phân loại theo từng loại mặt hàng và trạng thái tồn kho sau khi đã trừ đi số lượng mà phòng bán hàng yêu cầu, nếu kho hàng đó có phòng bán hàng.

Tìm kiếm các đơn hàng xuất

Ghi giao dịch nhập hàng

Cập nhật hàng về kho

Kiểm tra: hàng có serial?

Cập nhật trạng thái serial vào kho.

Tạo giao dịch nhập kho

Cộng kho hàng nhân viên.

1 NSD chọn nơi xuất hàng từ danh mục nơi xuất hàng:

- Loại kho: kho nhân viên, kho đại lý, kho cửa hàng, kho trung tâm, kho trung tâm viễn thông, kho công ty

2 NSD chọn lý do nhập từ danh mục lý do nhập

3 Người sử dụng chọn mặt hàng nhập từ danh mục hàng nhập:

4 NSD nhập các thông tin cho mỗi mặt hàng được đưa vào danh mục:

- Số lượng hàng thực nhập

- Số lượng hàng được yêu cầu nhập

Mặc định lần nhập số lượng yêu cầu đầu tiên thì lấy giá trị được nhập làm số lượng thực nhập

5 Nếu hàng có quản lý theo serial thì ghi các số serial sẽ được nhập

6 Nếu chọn tiếp hàng khác để nhập, quay lại bước 3

 Có mặt hàng chưa nhập số lượng hàng:

- Thông báo lỗi cho NSD biết chưa nhập số lượng hàng, bắt buộc phải nhập

 Nhập số lượng nhập lớn hơn số lượng yêu cầu nhập:

- Thông báo lỗi cho NSD biết, bắt buộc phải nhập lại

 Chọn mặt hàng và tình trạng để nhập đã có trong danh sách hàng cần nhập:

- Thông báo lỗi cho NSD, không cho nhập mặt hàng đó vào danh sách hàng cần nhập

 Số serial của mặt hàng cần QL theo serial chưa được nhập:

- Thông báo lỗi cho NSD, bắt buộc phải nhập

 Số serial của mặt hàng đã có trong danh sách hàng cần nhập:

- Thông báo lỗi cho NSD, bắt buộc nhập lại

 Số serial của mặt hàng đã có có trong kho:

- Thông báo lỗi cho NSD, bắt nhập lại

 Thủ kho chỉ được nhập hàng vào kho của đơn vị mình

 Hàng được nhập vào kho, số lượng hàng hiện có trong kho được cộng thêm

 Các số serial được nhập thuộc về kho

UC003 – Lập lệnh xuất kho

Tên Usecase: Lập lệnh xuất kho

Xem thông tin kho ôusesằ

 Nhân viên phòng bán hàng lập lệnh xuất kho cho quản lý bán hàng, đại lý, cửa hàng hoặc cho các kho cấp dưới tại trung tâm, chi nhánh

 Nhân viên cấp trên duyệt đề nghị xuất kho từ cấp dưới

Hệ thống Người sử dụng

Xem thông tin đơn hàng được chọn

Xem thông tin kho gửi đơn

Lấy thông tin chi tiết đơn hàng được chọn

Bổ sung, loại bỏ mặt hàng

Xem thông tin kho hiện tại

Hủy đơn hàng Bắt đầu

Lấy các mặt hàng và số lượng làm lệnh xuất Xem đơn hàng Điều chỉnh số lượng

1 NSD xem các đơn hàng được hệ thống lấy về

2 NSD chọn 1 đơn hàng cần xử lý từ danh mục đơn hàng nhận được

3 Hệ thống lấy thông tin chi tiết về đơn hàng được chọn

4 NSD xem thông tin đơn hàng chi tiết với các thông tin sau

- Mã các mặt hàng được đặt

- Tên các mặt hàng được đặt

- Trạng thái các mặt hàng được đặt

- Số lượng các mặt hàng được đặt theo trạng thái

5 NSD xem thông tin kho gửi đơn

(Xem - UC001 – Xem thông tin kho)

6 Nếu NSD quyết định không duyệt đơn chuyển sang bước 7

Nếu NSD duyệt đơn chuyển sang bước 8

Người sử dụng có khả năng tạo lệnh xuất hàng độc lập mà không cần dựa vào đơn hàng nào Để thực hiện điều này, người sử dụng cần chọn kho xuất hàng từ danh sách các kho cấp dưới thuộc kho của mình.

- Kho đích: Tên kho, mã kho

7 Hệ thống huỷ đơn hàng của kho đặt hàng: Xoá đơn hàng khỏi CSDL

8 NSD xem thông tin kho hiện tại để nắm được lượng hàng đang có trong kho

(Xem - UC001 – Xem thông tin kho)

9 Hệ thống tự động sao chép thông tin trong đơn hàng vào lệnh xuất, các thông tin bao gồm

- Số lượng yêu cầu theo mặt hàng

10 NSD chọn lý do xuất từ danh mục lý do xuất:

11 NSD bổ sung thêm hoặc loại bỏ một số mặt hàng trong yêu cầu xuất trong mục hàng được yêu cầu xuất bao gồm:

- Số lượng yêu cầu xuất Mặt hàng bổ sung được chọn từ danh mục thông tin kho hiện tại đã lấy ở bước 8: (Xem - UC001 – Xem thông tin kho)

12 NSD điều chỉnh số lượng xuất cho mỗi mặt hàng từ danh mục hàng cần xuất

13 Yêu cầu xuất được lưu vào CSDL, chuyển đến phòng kế toán

15 Nếu muốn tiếp tục xử lý đơn khác, quay lại bước 2

 Có mặt hàng chưa nhập số lượng hàng:

- Thông báo lỗi cho NSD biết chưa nhập số lượng hàng, bắt buộc phải nhập

 Số lượng hàng trong kho không đủ theo yêu cầu xuất:

- Thông báo lỗi cho NSD biết lượng hàng trong kho không đủ yêu cầu xuất, yêu cầu nhập lại

 Thêm mặt hàng đã được chọn để yêu cầu xuất:

- Thông báo lỗi cho NSD, không cho nhập mặt hàng đó vào danh sách hàng cần xuất

 Nếu NSD tạo mới một lệnh xuất không theo một đơn hàng nào thì kiểm tra nếu NSD chưa nhập ko được xuất hàng:

- Thông báo lỗi cho NSD, bắt buộc phải nhập

 Mặc định trạng thái mỗi mặt hàng khi nhập vào yêu cầu xuất là mới

 Phòng bán hàng tại kho nào được phép lập lệnh xuất hàng cho đơn hàng gửi đến kho đó

 Lệnh xuất kho được in

 Lệnh xuất kho được gửi tới phòng kế toán

 Đơn hàng đã được xử lý được loại bỏ khỏi danh sách các đơn hàng chưa được xử lý (chuyển trạng thái thành đã được xử lý)

UC004 – Lập phiếu xuất kho

Tên Usecase: Lập phiếu xuất kho

Xem lệnh xuất kho ôusesằ

Nhân viên kế toán lập phiếu xuất kho sau khi kiểm tra và xác nhận rằng kho hàng đã tuân thủ đầy đủ các quy định kế toán.

Hệ thống Người sử dụng

Lấy thông tin chi tiết đơn hàng được chọn

Bổ sung, loại bỏ mặt hàng Xem thông tin kho hiện tại

Hủy đơn hàng Bắt đầu

Lấy các mặt hàng và số lượng làm lệnh xuất Xem đơn hàng Điều chỉnh số lượng

1 NSD xem các lệnh xuất được gửi từ phòng bán hàng

Các lệnh xuất được liệt kê trên danh mục các lệnh xuất bao gồm:

- Kho được nhận hàng xuất

- Loại kho được nhận hàng xuất : kho đại lý, cửa hàng, quản lý bán hàng, trung tâm , chi nhánh

2 NSD chọn một lệnh xuất cần xử lý

3 Hệ thống truy cập CSDL lấy thông tin chi tiết lệnh xuất đã được chọn

4 NSD xem thông tin chi tiết lệnh xuất đã được chọn:

- Số lượng đề nghị xuất

5 NSD quyết định chấp nhận hoặc không chấp nhận lệnh xuất đã được chọn tùy thuộc các quy định kế toán

Nếu không chấp nhận sang bước

Nếu chấp nhận sang bước 7

6 Huỷ lệnh xuất và đơn hàng, chuyển sang bước 9

7 Phiếu xuất được lưu trữ vào CSDL và chuyển cho thủ kho cùng với lệnh xuất

9 Nếu NSD muốn xử lý lệnh khác, chuyển sang bước 2

Nếu không thì kết thúc

 Nhân viên phòng kế toán chỉ được xem các yêu cầu xuất từ phòng bán hàng tại kho của mình

 Phiếu xuất kho được in

 Phiếu xuất và lệnh xuất được gửi đến thủ kho

Lệnh xuất đã chuyển sang trạng thái được chấp nhận và được loại khỏi danh sách các lệnh xuất chờ chấp nhận của phòng kế toán Hiện tại, lệnh xuất đang ở trạng thái chờ đáp ứng từ thủ kho.

Hệ thống Người sử dụng

Chọn phiếu xuất Lấy thông tin chi tiết phiếu xuất

Xem thông tin phiếu xuất được chọn

In biên bản bàn giao Xuất mặt hàng khác

Chọn mặt hàng cần xuất

1 NSD xem thông tin kho (Xem -

UC001 – Xem thông tin kho):

- Số lượng đã được yêu cầu xuất

- Số lượng thực sự đang có trong kho

2 NSD chọn mặt hàng cần xuất từ danh mục hàng:

3 NSD nhập các thông tin cho mỗi mặt hàng được đưa vào danh mục:

- Số lượng hàng thực xuất

- Số lượng hàng được yêu cầu xuất

Mặc định lần nhập số lượng yêu cầu đầu tiên thì lấy giá trị được nhập làm số lượng thực xuất

4 Nếu hàng có quản lý theo serial thì ghi các số serial sẽ được xuất

5 Nếu chọn tiếp hàng khác để xuất, quay lại bước 2

 Có mặt hàng chưa nhập số lượng hàng:

- Thông báo lỗi cho NSD biết chưa nhập số lượng hàng, bắt buộc phải nhập lại

 Số lượng hàng thực nhập lớn hơn số lượng hàng yêu cầu nhập:

- Thông báo lỗi cho NSD, bắt buộc nhập lại

 Số lượng hàng trong kho không đủ theo yêu cầu xuất:

- Thông báo lỗi cho NSD biết lượng hàng trong kho không đủ yêu cầu xuất, yêu cầu nhập lại

 Chọn mặt hàng và tình trạng để xuất đã có trong danh sách hàng cần xuất:

- Thông báo lỗi cho NSD, không cho nhập mặt hàng đó vào danh sách hàng cần xuất

 Số serial của mặt hàng cần QL theo serial chưa được nhập:

- Thông báo lỗi cho NSD, bắt buộc phải nhập mới được xuất hàng

 Số serial của mặt hàng đã có trong danh sách hàng cần xuất:

- Thông báo lỗi cho NSD, bắt buộc nhập lại

 Số serial của mặt hàng không có trong kho:

- Thông báo lỗi cho NSD, bắt nhập lại

 Thủ kho chỉ được xuất hàng tại kho của đơn vị mình

 Nhân viên bán hàng, quản lý bán hàng, chủ đại lý được xuất hàng khỏi kho cá nhân

Nếu chủ đại lý hoặc nhân viên bán hàng không có máy tính, nhân viên phòng bán hàng và quản lý bán hàng sẽ thực hiện các công việc thay cho họ.

 Hàng được xuất khỏi kho, số lượng hàng hiện có trong kho được trừ đi

 Các số serial được xuất không còn ở trong kho

UC006 – Xuất hàng cho nhân viên

Tên Usecase: Xuất hàng cho nhân viên

Xuất hàng - nhân viên nhận hàng

Xem thông tin kho ôextendsằ

Nhập hàng - Nhân viên nhận hàng Nhập hàng

Xuất hàng ôusesằ ôusesằ ôextendsằ

Quản lý bán hàng, thủ kho cửa hàng giao hàng cho nhân viên bán hàng

Xuất hàng cho nhân viên bán hàng trực tiếp

Hệ thống Người sử dụng

Xem thông tin kho nhân viên

Nhập hàng vào kho nhân viên Xuất cho nhân viên khác

1 NSD xem thông tin kho để biết được lượng hàng trong kho

(Về usecase xem thông tin kho – Xem UC001 – Xem thông tin kho)

2 NSD chọn nhân viên nhận hàng từ danh mục nhân viên bán hàng do mình quản lý”

3 NSD xem thông tin kho của nhân viên để nắm được số lượng hàng trong kho của nhân viên

(Về usecase xem thông tin kho – Xem UC001 – Xem thông tin kho)

4 NSD chọn lý do xuất từ danh mục xuất:

5 NSD chọn mặt hàng cần xuất cho

NV từ danh mục hàng:

6 NSD nhập số lượng mặt hàng cần xuất cho nhân viên và tình trạng hàng tương ứng

7 NSD ghi các số serial được xuất

(theo dải hoặc từng số serial lẻ một)

8 Nếu chọn tiếp mặt hàng khác, quay lại bước 5

9 Hàng được xuất khỏi kho cửa hàng

10 Hàng được nhập vào kho nhân viên

12 Nếu muốn xuất cho nhân viên khác, quay lại bước 2

Nếu không muốn xuất tiếp thì kết thúc

 Bao gồm các sự kiện phụ trong UC005 - Xuất và UC002 – Nhập

 Số lượng serial được chọn để xuất không đúng với số lượng hàng cần xuất:

- Thông báo lỗi cho NSD biết, bắt buộc nhập lại

 Bao gồm các yêu cầu đặc biệt trong UC005 - Xuất và UC002 – Nhập

 Khi hàng đến kho nhân viên, các số serial được lưu trũ thành từng số serial một

 Bao gồm các tình trạng trước trong UC005 - Xuất và UC002 – Nhập

 Bao gồm các tình trạng sau trong UC005 - Xuất và UC002 – Nhập

 Hàng đã được xuất khỏi kho cửa hàng

 Hàng được chuyển vào kho nhân viên

UC007– Nhập hàng- Nhân viên nhận hàng

Tên Usecase: Nhập hàng - Nhân viên nhận hàng

Nhập hàng - nhân viên nhận hàng

Hàng sau khi được quản lý bán hàng xuất sẽ được nhập vào kho của nhân viên bán hàng

Usecase được hệ thống thực hiện tự động trong use case UC006 – Xuất hàng cho

Nhập hàng - Nhân viên nhận hàng

Nhận danh mục hàng được nhập

Ghi số serial được nhập

Nhập hàng vào kho nhân viên

1 Nhận danh mục hàng được nhập:

- Tình trạng hàng khi nhập

- Các số serial được nhập

2 Ghi các số serial được nhập

3 Hàng được nhập vào kho nhân viên bán hàng

Bao gồm các dòng sự kiện phụ trong UC002 – Nhập

 Bao gồm các yêu cầu đặc biệt trong UC002 – Nhập

 Các số serial được ghi thành từng số một cho dù mặt hàng được quản lý theo dải serial

 Bao gồm các tình trạng trước trong UC002 – Nhập

 Bao gồm các Tình trạng sau trong UC002 – Nhập

UC008 – Xuất kho tiêu thụ

Tên Usecase: Xuất kho tiêu thụ

Nhân viên cửa hàng cấp trên xuất kho cho đại lý trực thuộc

Usecase được hệ thống thực hiện tự động thông qua usecase bán hàng hóa vật tư

Chọn lý do bán Chọn dịch vụ

Nhập danh mục hàng bán

Chọn giá mặt hàng + số lượng

Kiểm tra: hàng có serial?

Nhập thêm mặt hàng khác?

1 NSD nhập các thông tin đơn hàng cần bán:

2 Nhấn [Thêm] để thêm mới mặt hàng giao dịch

Nhập thông tin mặt hàng giao dịch

Số lượng Nhấn [Cập nhật]

3 Kiểm tra mặt hàng có quản lý theo serial hay không

Nếu có thực hiện bước 4

Nếu không thực hiện bước 5

4 Tìm kiếm serial mặt hàng được quản lý trong kho

Chọn serial cần thực hiện giao dịch Nhấn [Cập nhật]

(Người dùng có thể chọn các mặt hàng khác cho đơn hàng)

5 Hệ thống tạo giao dịch thành công

6 Hệ thống thực hiện trừ số lượng hàng trong kho giao dịch viên

Hệ thống thực hiện cập nhật trạng thái serial = đã xuất, và kết thúc giao dịch

 Bao gồm các sự kiện phụ trong UC005 - Xuất

 Bao gồm các yêu cầu đặc biệt trong UC005 - Xuất

 Bao gồm các tình trạng trước trong UC005 - Xuất

 Bao gồm các tình trạng sau trong UC005 - Xuất

Chúng tôi sẽ phát triển một phần mềm dựa trên các thành phần có sẵn bằng ngôn ngữ lập trình Java Các thành phần JavaBean sẽ được đóng gói và biên dịch thành file JAR, bao gồm các file class và tài nguyên cần thiết để phục vụ cho các lời gọi trên từng file thống kê, cung cấp thông tin chi tiết về chúng.

Sau khi tích hợp các thành phần vào chương trình xây dựng và phát triển, chúng ta tiến hành kiểm thử dựa trên các thành phần đã được tích hợp để xây dựng form chức năng hoàn chỉnh.

Các cấu phần này hiển thị trong frame ToolBox:

Khi thực thi chương trình, form hiển thị:

4.4.4 Các bước thực hiện chương trình

Servlet là một nền tảng cấu phần cho phép phát triển ứng dụng web độc lập, vượt qua các giới hạn của chương trình CGI Khác với các cơ chế mở rộng riêng lẻ của từng server như Netscape Server API hay các module của Apache, servlet hoạt động trên nền tảng độc lập với server.

Vòng đời servlet bao gồm các bước:

Class servlet được load bởi trình bao gói trong suốt thời gian khởi động

Phương thức init() trong trình bao gói khởi tạo servlet và cần được gọi trước khi servlet có thể xử lý bất kỳ yêu cầu nào Trong suốt vòng đời của servlet, phương thức này chỉ được gọi một lần duy nhất.