Nghiên cứu kỹ thuật kiểm thử phần mềm trên cơ sở mô hình UML

Thuật ngữ QTDA Project manager Quản trị dự án CNPM Software engineering Công nghệ phần mềm CBSE Component-base software engineering Công nghệ phần mềm trên cơ sở cấu phần RM-ODP Referen

VĂN THỊ HỒNG PHÚC

NGHIÊN CỨU KỸ THUẬT KIỂM THỬ PHẦN MỀM

TRÊN CƠ SỞ MÔ HÌNH UML

LUẬN VĂN THẠC SĨ

Hà Nội - 2009

Chương 1: Giới thiệu 1

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

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

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

Chương 2: Một số khái niệm cơ bản 4

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

2.1.1 Chuẩn tương tác [3] 6

2.1.2 Chuẩn kết hợp [3] 7

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

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

2.3.1 Mô hình cấu phần 12

2.3.2 Sự cài đặt mô hình cấu phần và các dịch vụ 16

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

2.4.1 Mục tiêu của UML 19

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

2.4.3 Các công cụ xây dựng UML 22

2.5 Lý thuyết kiểm thử 24

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

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

2.5.3 Vai trò của kiểm thử trong phát triển phần mềm 28

Chương 3: Kiểm thử trên cơ sở các mô hình UML 34

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

3.2 UML và kiểm thử 35

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

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

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

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

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

3.4.1 Mô hình tương tác 50

3.4.2 Mô hình hành vi 51

3.4.3 Cấu trúc điều khiển 52

3.4.4 Các quan hệ về tương tác dữ liệu 52

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

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 55

3.5.2 Các tiếp cận kiểm thử tích hợp trên cơ sở UML 58

Chương 4: Thực nghiệm kiểm thử phần mềm 64

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

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

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

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

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

4.4.2 Quản lý kho 70

4.4.3 Xây dựng chương trình 94

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

4.4.5 Xây dựng các tình huống kiểm thử 97

Kết luận 103

Tóm tắt kết quả chính đã đạt được 103

Tồn tại và hướng phát triển 104

Tài liệu tham khảo 106

# Tên danh mục hình Trang

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

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

7 Hình 7: Lược đồ biểu diễn cấu trúc một ca kiểm thử 39 Hình 8: Lược đồ biểu diễn các use case quản lý giao dịch ATM 40

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

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

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

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

12 Hình 13: Tập điều kiện kiểm tra phụ thuộc 57

13 Hình 14: Mô hình cộng tác mô tả hoạt động giao dịch của máy

14 Hình 15: Mô hình tuần tự mô tả giao dịch ATM 60

15 Hình 16: Mô hình trạng thái phục vụ của máy ATM 61

16 Hình 17: Mô hình cấu phần phục vụ giao dịch gửi/rút tiền ATM 63

18 Hình 19: Ví dụ xây dựng trên nền javabean 64

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

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

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

DANH MỤC BẢNG

Bảng 1 So sánh vòng đời phát triển phần mềm 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 11 Bảng 2 Các yếu tố cơ bản trong kiểm thử 32

Thuật

ngữ

QTDA Project manager Quản trị dự án

CNPM Software engineering Công nghệ phần mềm

CBSE Component-base software

engineering

Công nghệ phần mềm trên cơ

sở cấu phần RM-ODP Reference Model of Open

ADT Abstract data type Kiểu dữ liệu trừu tượng

UML Unified Modeling Language Ngôn ngữ mô hình hoá thống

nhất OMG Object Management Group Nhóm quản lý đối tượng

COM Component Object Model Mô hình đối tượng cấu phần CSLC Component Software Life Cycle Vòng đời phần mềm cấu phần RTE Real-time and embedded system Hệ thống nhúng và thời gian

thực IDL Interface Definition Language Ngôn ngữ định nghĩa giao diện HTTP HyperText Transfer Protocol Giao thức truyền siêu văn bản XML eXtensible Markup Language Ngôn ngữ đánh dấu mở rộng IDE Interactive development

environment

Môi trường phát triển tương tác

QoS Quality of Service Chất lượng dịch vụ

HĐH Operating system Hệ điều hành

CIG Component Interaction graph Lược đồ tương tác cấu phần COTs Commercial components Các cấu phần thương mại

OMA Object management

architechture

Nhóm quản lý đối tượng

SUT System under test Kiểm thử hệ thống

DF Developing for reuse Cấu phần phát triển để sử dụng

lại

DW Developing with reuse Cấu phần sử dụng lại

Trước hết tôi xin gửi lời cảm ơn đặc biệt nhất tới PGS.TS Đặng Văn Đức viện Công nghệ thông tin người đã định hướng đề tài và tận tình hướng dẫn chỉ bảo tôi trong suốt quá trình thực hiện luận văn cao học này

Tôi xin được gửi lời cảm ơn sâu sắc tới Trung tâm Đào tạo Sau đại học và các thầy

cô giáo trong Khoa Công nghệ thông tin, Trường Đại học Quốc Gia Hà Nội đã tận tình giảng dạy và truyền đạt những kiến thức, những kinh nghiệm quý báu trong suốt 2 năm học Cao học

Tôi xin bày tỏ lòng cảm ơn chân thành tới tất cả các bạn bè, các thầy cô giáo, các đồng nghiệp Khoa Công nghệ thông tin, Trường Đại học Quốc Gia Hà Nội đã động viên, tạo điều kiện cho tôi trong suốt thời gian thực hiện luận văn này

Cuối cùng tôi xin dành một tình cảm biết ơn tới Bố, Mẹ, những người đã luôn luôn

ở bên cạnh tôi, động viên, chia sẻ cùng tôi trong suốt thời gian học cao học cũng như quá trình thực hiện luận văn cao học

Hà Nội, ngày 30 tháng 6 năm 2009

Văn Thị Hồng Phúc

LỜI CAM ĐOAN

Tôi xin cam đoan: Luận văn “Nghiên cứu kỹ thuật kiểm thử phần mềm trên

cơ sở mô hình UML” là công trình nghiên cứu riêng của tôi

Các kết quả nghiên cứu trong luận văn là trung thực Nếu sai tôi xin hoàn toàn chịu trách nhiệm

Hà Nội, ngày 30 tháng 6 năm 2009

Học viên

Văn Thị Hồng Phúc

Chương 1: Giới thiệu

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

Kiểm thử là một khâu không thể thiếu trong quá trình phát triển phần mềm Nhiều hệ thống phần mềm thất bại là do không tìm ra lỗi Nguồn lực sử dụng cho khâu kiểm thử là một yêu cầu khá lớn trong quá trình phát triển phần mềm Quá trình kiểm thử yêu cầu một số pha kết hợp gồm: 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) đã thể hiện rõ tính ưu việt trong phát triển phần mềm Trong đó, tính đóng gói, trừu tượng hóa và tính sử dụng lại làm tăng chất lượng phần mềm Theo Paul Allen thì hiện nay có đến hơn 70% hệ thống phần mềm mới được phát triển dựa trên cơ sở cấu phần Các cấu phần thường được phát triển theo hướng đối tượng và được viết bằng các ngôn ngữ khác nhau, chạy trên các môi trường khác nhau, có thể phân tán khắp nơi và người phát triển phần mềm mới không được cung cấp các mã nguồn Các đặc tính này là nguyên nhân gây nhiều khó khăn trong việc kiểm thử hệ thống phần mềm Để tăng tính mềm dẻo khi nhìn nhận các chức năng, đặc điểm phần mềm xây dựng, chúng ta sử dụng ngôn ngữ mô hình hóa chuẩn UML

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

Thực tế cho thấy phương pháp Phát triển phần mềm theo cấu phần đã làm giảm chi phí của dự án phát triển phần mềm So với công nghệ truyền thống chuẩn, công nghệ phần mềm trên cơ sở cấu phần quan tâm đến cách xây dựng phần mềm nhiều hơn Thông qua việc sử dụng lại các cấu phần, vòng đời phát triển phần mềm được rút ngắn lại, đồng thời tăng tính mềm dẻo khi sử dụng và

bảo trì phần mềm Hơn nữa, phát triển phần mềm có khả năng làm tăng chất lượng phần mềm Với tầm quan trọng như trên, đã có nhiều kết quả nghiên cứu

lý thuyết và sản phẩm công cụ hỗ trợ phát triển phần mềm trên cơ sở cấu phần Nội dung luận văn này nhằm mục tiêu khảo sát các vấn đề cơ bản và kỹ thuật phát triển phần mềm theo cấu phần Đặc biệt luận văn tập trung vào kỹ thuật kiểm thử phần mềm phát triển dựa theo cấu phần với mục đích hướng tới ứng dụng thực tế tại Việt Nam

1.2 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 IBM, viết cuốn The Mythical Man-month Bài luận ngắn trong trong cuốn sách này mô tả những khó khăn khi phát triển phần mềm phức tạp, Brooks viết một chương với tiêu đề là

“No Silver Bullet” giải thích rằng các hệ thống phần mềm là phức tạp Ông dự đoán sẽ không có kỹ thuật nào là duy nhất – no silver bullet – mà nó có thể cải thiện năng suất theo danh sách yêu cầu cho mọi hệ thống Trong chương này, Brooker trích dẫn ra các lý do gây nên “khủng hoảng phần mềm”, và khủng hoảng này sẽ còn tiếp tục cho đến khi một kỹ thuật mới như công nghệ phần mềm trên cơ sở cấu phần (CBSE – Component based software engineering) trở nên có tính khoa học và nó thực sự dựa trên tính khoa học

Và như thế, CBSE đã đưa ra được “Những bài học hay nhất” về sản phẩm công nghệ phần mềm trong suốt 30 năm tiếp theo Brooks trình bày 2 phương pháp khả thi giúp giảm mức độ phức tạp của phần mềm đó là “Buy before Build” và “Reuse before Buy” Các khái niệm mấu chốt được đưa ra nhằm giúp giảm được chi phí trong công nghệ phát triển phần mềm

Trong hội nghị thảo luận năm 1968, NATO đã tham gia tranh luận về thuật

ngữ khủng hoảng phần mềm Thêm nhiều thuật ngữ khó hiểu như kẽ hở phần

mềm, … các thuật ngữ này dần dần được làm rõ khi trong quá trình phát triển

công nghệ phần mềm Theo David và Fraser phát biểu năm 1968, “ Kẽ hở được phát hiện tại thời điểm khi mà hậu quả việc hỏng hóc phần mềm tăng theo mọi mức độ nghiêm trọng” Để phát triển phần mềm trên cơ sở cấu phần chúng ta phải học cách xây dựng các cấu phần đó dựa vào các yêu cầu, hoặc dựa trên việc thiết kế các module thành phần hay các thiết kế trực tiếp các cấu phần Các khách hàng đặt hàng (các cấu phần) và việc tích hợp các cấu phần cung cấp bởi nhà sản xuất sẽ đảm bảo rằng nó đáp ứng được yêu cầu khách hàng với các mong muốn họ đưa ra

Khái niệm về mô hình của cấu phần phần mềm được phát triển rộng rãi bởi BradCox và đặt nền móng cho việc tạo một 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 (Nội dung được đúc kết trong cuốn sách Oriented Programming – An Evolution Approach 1986)

Object-IBM tiên phong mở ra lối nghiên cứu về Mô hình đối tượng hệ thống ngay đầu những năm 1990 Một số các đóng góp được ứng dụng trong phần mềm cấu phần đó là OLE và COM Mô hình cấu phần phần mềm vẫn tiếp tục thu được những thành quả đáng kể

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

Luận văn này nhằm mục tiêu nghiên cứu khảo sát sơ bộ các kỹ thuật kiểm thử phần mềm, với giải pháp áp dụng các mô hình UML vào kiểm thử phần mềm trên cơ sở cấu phần Từ đó, áp dụng các kết quả nghiên cứu lý thuyết vào thực nghiệm kiểm thử một thiết kế phần mềm cụ thể mà luận văn đưa ra

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ử

Chương 2: Một số khái niệm cơ bản

Lập trình hướng cấu phần (COP – Component oriented programming) và công nghệ phần mềm trên cơ sở cấu phần (CBSE – Component based software engineering) đôi khi có thể hiểu là một Tuy nhiên, CBSE là thuật ngữ rộng hơn,

và COP chỉ là một phần trong đó

CBSE = COA + COD + COP + COM

Trong đó COA (component oriented analysis), COD (Component oriented design) và COM (Component oriented management) thể hiện các thuật ngữ về phân tích hướng cấu phần, thiết kế hướng cấu phần và quản lý hướng cấu phần Mục tiêu của CBSE là phát triển phần mềm một cách nhanh chóng, và giảm chi phí bằng cách xây dựng các hệ thống thông qua việc thu thập các cấu phần có sẵn Thiết kế, phát triển, và duy trì các cấu phần nhằm mục đích sử dụng lại là một quy trình rất phức tạp, với các yêu cầu ở mức cao không chỉ đáp ứng được tính chức năng và mềm dẻo cấu phần mà còn đáp ứng việc phát triển phần mềm một cách có tổ chức CBSE bao gồm rất nhiều các nguyên tắc công nghệ phần mềm và các kỹ thuật khác nhau

Trong công nghệ phần mềm truyền thống, quy trình phát triển phần mềm bao gồm các hoạt động hoặc các trạng thái tuần tự, cách đặt tên, phân tích, thiết kế, ngôn ngữ lập trình, kiểm thử, và tích hợp Trong CBSE, các giai đoạn phát triển chính vẫn tuân thủ theo các bước thực hiện như quy trình phát triển truyền thống, và bổ sung thêm bước tập hợp và lắp ghép các cấu phần Ta có thể nhận thấy rằng, điểm nổi bật trong CBSE so với công nghệ phần mềm truyền thống chính nằm ở hướng thiết kế, bước thu thập và lắp ghép các cấu phần vào việc xây dựng một hệ thống hoàn thiện

Dưới cách nhìn về các cấu phần, có 2 loại hoạt động căn bản đó là: Phát triển cấu phần để sử dụng lại (DF – Developing for reuse) và sử dụng lại các cấu phần

đã có sẵn (DW - Developing with reuse) Với việc phát triển cấu phần để sử dụng lại có thể được tổ chức theo cách tiếp cận công nghệ phần mềm truyền thống, nhấn mạnh vào các chuẩn cấu phần Mỗi cấu phần cung cấp 2 loại giao diện: (1) giao diện cung ứng – định nghĩa các dịch vụ quảng bá cấu phần này sẽ cung ứng và (2) giao diện yêu cầu – đặc tả các dịch vụ mà cấu phần cần đến để thể hiện khả năng làm việc

Theo các nhìn hướng quy trình công nghệ, có 5 cách định nghĩa khác nhau trong CBSE:

1 Đặc tả cấu phần (Component specification): Nó thể hiện đơn vị đặc tả của

phần mềm, mô tả hành vi của tập các đối tượng cấu phần và định nghĩa một đơn

vị thực hiện Hành vi được định nghĩa dưới dạng tập các giao diện Một đặc tả cấu phần được nhận diện dưới dạng một thực thi cấu phần

2 Giao diện cấu phần (Component interface): Giao diện thể hiện định nghĩa

tập các hành vi có thể được cung ứng thông qua một đối tượng cấu phần

3 Sự thực thi cấu phần (Component implementation): Là một sự nhận diện

của đặc tả cấu phần, có khả năng triển khai độc lập Điều này nghĩa là nó có thể

được cài đặt và thay thế một cách độc lập các cấu phần khác Như thế không có nghĩa là nó độc lập với các cấu phần khác – nó có rất nhiều sự phụ thuộc

4 Cấu phần được cài đặt (Installed component): Là sự sao chép của

một thực thi cấu phần dưới hình thức cài đặt (hoặc triển khai) Một sự thực thi cấu phần được triển khai bằng cách đăng ký nó với môi trường

khi chạy thật Môi trường chạy thật định nghĩa khả năng của cấu phần

được cài đặt nhằm tạo một thể hiện khi thực hiện bước vận hành nó

5 Đối tượng cấu phần (Component object): Một đối tượng cấu phần là một

thể hiện của cấu phần được cài đặt Khái niệm này khá giống với khái niệm trong lập trình hướng đối tượng, một đối tượng cấu phần trong lập trình hướng cấu phần là một đối tượng có dữ liệu riêng và định nghĩa duy nhất, nó thực hiện

hành vi thực thi xác định Một cấu phần cài đặt có thể có các đối tượng cấu

phần đa nhiệm hoặc đơn nhiệm

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

Để tìm hiểu, nghiên cứu về mục tiêu mà luận văn đã đề ra, trước tiên, ta đi vào việc tìm hiểu các thuật ngữ cơ bản được sử dụng trong CBSE, ta đi từ các khái niệm nhỏ nhất, đơn giản nhất về cấu phần

Một phần tử phần mềm chứa chuỗi các lệnh cấp cao, các tính toán được thực

hiện bởi máy tính Phần tử phần mềm là thực thi nếu: (1) máy tính trực tiếp thực thi các lệnh hoặc (2) có một bộ thông dịch chạy trên máy tính dịch các câu lệnh sang dạng máy thực thi được

Mã nguồn phần mềm là tập các file máy có thể đọc được, chứa các câu lệnh

chương trình được viết ứng với một ngôn ngữ lập trình Các câu lệnh này được dịch thành các câu lệnh thực thi được hoặc nhờ vào 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 đó được cài đặt, và đưa vào sử dụng Sự khác nhau giữa phần tử phần mềm và cấu phần phần mềm được thể hiện ở cách sử dụng Phần mềm bao gồm rất nhiều yếu tố trừu tượng, các đặc trưng chất lượng Đó là thước đo để đánh giá một cấu phần hay một 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 đặt trong phạm vi mô tả về cấu phần phần mềm như sau:

 Một cấu phần phần mềm là một phần tử phần mềm tuân theo một mô hình

cấu phần và có thể triển khai độc lập, được kết hợp mà không cần sửa đổi theo một 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 là một tập hợp các phần tử phần mềm xác

định cần có để hỗ trợ việc thực thi của các cấu phần tuân theo mô hình

 Hạ tầng của cấu phần phần mềm, là một tập hợp các cấu phần phần mềm

tương tác được thiết kế để đảm bảo rằng hệ thống phần mềm được xây dựng sử dụng các cấu phần và giao diện này sẽ thỏa mãn các đặc tả hiệu năng đã định nghĩa

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

Khả năng của cấu phần và cách dùng nó được đặc tả bởi giao diện Giao diện

là một sự trừu tượng hóa dịch vụ, nó định nghĩa các thao tác mà dịch vụ hỗ trợ,

nó độc lập với bất kỳ sự thực thi đặc biệt nào Một cấu phần phần mềm giao tiếp

và tương tác 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 và tương tác sẽ cho chúng ta biết được nó làm gì (what), nội dung của mã thực thi trong cấu phần, quy trình xử lý (how) được ẩn hoàn toàn và người sử dụng cấu phần không phải quan tâm tới việc nó làm như thế nào

2.1.1 Chuẩn tương tác [3]

Chuẩn giao diện là các yêu cầu bắt buộc phải sử dụng và tuân theo đối với

cấu phần phần mềm để các phần tử phần mềm tương tác trực tiếp với các phần

tử khác Chuẩn giao diện khai báo một giao diện có thể chứa cái gì

Cấu phần cung cấp một giao diện cung ứng nếu cấu phần đó chứa sự cài đặt tất cả các thao tác được định nghĩa bởi giao diện Một cấu phần cần một giao

diện yêu cầu, nếu cấu phần đó đòi hỏi một tương tác được định nghĩa trong giao

diện này và nó giả thiết rằng có phần tử phần mềm nào đó sẽ cung cấp giao diện này Một cấu phần không thể cung cấp một giao diện cung ứng, nếu thiếu một trong số giao diện yêu cầu của nó Vì vậy, lý tưởng nhất, một cấu phần cần được triển khai với thông tin mô tả đặc tả 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 một cấu phần thông qua việc sử dụng các giao diện được định nghĩa rõ ràng và được tài liệu hóa Một chuẩn tương tác định nghĩa các phần tử của một giao diện Nếu cấu phần chỉ có thể thực hiện chức năng của nó bằng cách tương tác với phần tử phần mềm khác, tất cả các phụ thuộc bối cảnh phải được đặc tả tường minh trong tài liệu cấu phần Chuẩn tương tác bao gồm 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ó một phụ thuộc bối cảnh tường minh trên HĐH, một cấu phần phần mềm, hoặc một phần tử phần mềm khác Một chuẩn tương tác

đặc tả dạng các phụ thuộc bối cảnh tường minh mà cấu phần có thể có Một dạng khác của phụ thuộc bối cảnh tường minh xảy ra khi một cấu phần phải chạy trên một máy tính với một xung nhịp xác định để đạt được hiệu năng mong muốn Nếu cấu phần phải tương tác với một 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 - Application Programming Interfaces) của HĐH hoặc giao diện của cài đặt mô hình cấu phần Trong cả hai trường hợp, thông tin mô tả cấu phần phải định nghĩa rõ ràng phụ thuộc bối cảnh tường minh này

Để có thể 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ấu phần phải thống nhất được tập các giao diện trước khi thiết kế Kết quả của sự thoả thuận này là các giao diện được chuẩn hoá Mặt khác, các giao diện

có thể được mô tả bằng cách sử dụng nhiều ký pháp khác nhau, nó phụ thuộc vào thông tin mà chúng ta muốn chứa đựng, và mức chi tiết của đặt tả Phần giao diện chỉ mô tả tên của các phương thức, kiểu của các tham số, và giá trị trả

về tức là nó chỉ cung cấp các đặc tả của tập các thao tác chứ không phải 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:

1) Cài đặt cấu phần

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 và mô-đun) và máy có thể thực thi (các thư viện lúc thực thi và các

mã đối tượng được biên dịch sẵn), được đóng gói thành phần tử phần mềm máy đọc được Một cấu phần phần mềm được đóng gói dạng nhị phân nhằm:

 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 các phụ thuộc bối cảnh tường minh (ví dụ: người dùng không cần chương trình dịch Gnu C++ phiên bản 2.81 sử dụng cấu phần được đóng gói dạng nhị phân)

Trong quá trình triển khai, có thể khách hàng hoặc bên chứng nhận thứ ba sẽ

có yêu cầu đòi quyền truy cập mã nguồn Khi đó, nhà sản xuất cấu phần sẽ quyết định về việc triển khai mã nguồn của cấu phần đó

Một chuẩn kết hợp định nghĩa cách thức soạn cấu phần để tạo ra một cấu trúc lớn hơn, cách thức mà một nhà sản xuất thay thế cấu phần bằng cấu phần khác theo cấu trúc đã có sẵn

Thêm vào đó, với một mô tả giao diện, nhà sản xuất cấu phần cần cung cấp tài liệu mô tả đầy đủ tới người dùng cấu phần tương lai, để người dùng có khả năng gắn cấu phần đó vào trong một ứng dụng cụ thể Bên chứng nhận thứ ba cũng sẽ sử dụng tài liệu được cung cấp để kiểm chứng quy trình được sử dụng phát triển cấu phần đó và đảm bảo rằng sản phẩm cuối cùng đáp ứng được đầy

đủ đặc tả Nhà sản xuất cấu phần hoặc tổ chức chứng nhận thứ ba sẽ quyết định dạng thích hợp nhất cho tài liệu, đó là lưu trữ nó cùng với cấu phần theo cả hai dạng mã nguồn hoặc nhị phân, hay cung cấp độc lập Điểm mạnh của phần mềm phát triển trên cơ sở cấu phần được thể hiện ở:

 Quy tắc nghiệp vụ

 Quy trình nghiệp vụ

 Các yêu cầu chức năng

 Các yêu cầu phi chức năng

 Các chuỗi tình huống sử dụng

 Tài liệu thiết kế sử dụng các lược đồ UML và ngôn ngữ ràng buộc đối tượng

 Các điều kiện trước

 Các điều kiện sau

 Các hợp đồng thiết kế

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

Mặc dù trong lĩnh vực công nghiệp phần mềm, công nghệ phần mềm trên cơ

sở cấu phần (CBSE – component base softwar engineering) được coi là nền tảng vững chắc, nhưng đứng về phương diện là một khoa học công nghệ thì nó vẫn còn khá non nớt Thực tế cho thấy, các quy trình thành công cần phải được chia

sẻ như các bài thực hành tốt nhất để có nhiều tổ chức hơn thành công với CBSE Vấn đề trước hết là các tổ chức phát triển phần mềm và các phòng dịch vụ thông tin thường có ghanh đua về vấn đề quy trình đã được đăng ký Ví dụ, nếu một nhà quản lý dịch vụ thông tin thất bại khi chuyển giao một hệ thống phần mềm,

họ sẽ có một lựa chọn là sử dụng toàn bộ nguồn lực bên ngoài Nếu bạn cho rằng nguồn lực sẵn có, nguồn lực bên ngoài và các công cụ phát triển là không

có gì mới mẻ so với việc phát triển phần mềm thong thường, thì sự khác nhau chính là ở quy trình được sử dụng để phát triển hệ thống phần mềm

Trọng tâm của quy trình xây dựng giải pháp (Allen và Frost 1998) được đưa

ra bởi khách hàng hoặc doanh nghiệp (Eles và Sims, 1998) Trong lĩnh vực công nghệ phần mềm Điều này luôn đạt được bằng việc mô hình hóa các quy trình nghiệp vụ (Jacobson 1994) Thỏa thuận giữa khách hàng và nhà thiết kế đạt được thông 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 việc thiết kế giải pháp được bắt đầu, các cấu phần bắt đầu có một ảnh hưởng nào

đó Nhóm chịu trách nhiệm xây dựng các giải pháp thực sự là thành phần chi phối đến dự án Một lựa chọn cho thiết kế các cấu phần tương tác là dựa trên mô hình UML Thách thức cho người xây dựng giải pháp là tập hợp thành hệ thống lớn trên cơ sở các cấu phần Để làm được điều này ta sẽ cần thông tin về các cấu phần có sẵn, các giao diện yêu cầu, các dịch vụ, sự vận hành, và các phương thức

Quy trình tìm đúng các cấu phần là quan trọng với nhà thiết kế, và thuật ngữ

thường được sử dụng trong quá trình thiết kế là lấp đầy khoảng trống Quá trình

lấp khoảng trống có thể đưa đến một trong hai kết luận sau:

i) Cấu phần giống như yêu cầu đã được tìm thấy và đưa vào sử dụng ii) Không có cấu phần nào như thế tồn tại

Điều này dẫn đến đòi hỏi đó là cần có một quy trình lưu trữ các cấu phần có sẵn, đôi khi bạn cũng cần tạo một dự án con để xây dựng một cấu phần theo đặc

tả Điều này có nghĩa là quy trình lưu trữ không chỉ nắm giữ các các cấu phần đã

xây dựng sẵn, mà còn kích hoạt quy trình xây dựng cấu phần mới Lợi ích thực

sự của CBSE chỉ được nhận ra bằng cách kích hoạt song song giải pháp và sự phát triển cấu phần, điều này đạt được thông qua việc lập kế hoạch và thiết kế Với các cấu phần không tìm thấy, quy trình lưu trữ phải cho phép khách hàng đưa ra mong muốn để nhận được sự cung ứng khác

Mỗi lần ta sử dụng một cấu phần cho dù cấu phần đó đã được đóng gói hay

đã được gắn vào sản phẩm, ta cũng cần một quy trình quản lý cấu hình cấu phần

đó Bởi vì các phiên bản mới của một cấu phần có thể được cung ứng bất cứ lúc nào, và người xây dựng giải pháp có thể muốn cải tiến nâng cấp, hay khách hàng cần một quy trình thông báo cho họ khi các cấu phần cập nhật, lưu trữ Người xây dựng giải pháp có thể dễ dàng thay thế một cấu phần tồn tại bằng phiên bản mới hơn Điều này đạt được nếu người xây dựng giải pháp có xác nhận đăng ký nhận thông báo khi có cấu phần phiên bản mới được lưu trữ

Thêm một định nghĩa nữa ở đây để ta có thể phân biệt sự khác nhau giữa vòng đơi phát triển phần mềm và vòng đời cấu phần đó là: Trong một vòng đời phát triển phần mềm truyền thống, những người phát triển thường là người phân tích, thiết kế và lập trình Một dự án có một sự khởi đầu tốt, khi các yêu cầu trở nên rõ ràng, và kết thúc tốt đẹp khi hệ thống phần mềm cuối cùng sẽ được chuyển giao Sản xuất cấu phần thì khác, người ta mất nhiều thời gian hơn để nghiên cứu về các quy tắc nghiệp vụ, mô hình quy trình nghiệp vụ, phân tích và thiết kế Nhưng thời gian sử dụng để phát triển là ít hơn trong khi kiểm thử phải thực hiện xuyên suốt Để tìm hiểu một cách chi tiết về vòng đời cấu phần ta đi đến định nghĩa sau:

Vòng đời phần mềm cấu phần (CSLC-Component Software Life Cycle)[3]

biểu diễn quy trình trọn vẹn để phát triển một phần mềm có sử dụng đến tích hợp cấu phần bên ngoài CSLC nhấn mạnh vào: các quy tắc nghiệp vụ, mô hình quy trình nghiệp vụ, thiết kế, xây dựng, duy trì kiểm thử, triển khai, mở rộng, duy trì sử dụng lại và bảo trì

Các giai đoạn phân tích và thiết kế cho 1 CSLC là đặc biệt dài hơn so với vòng đời phát triển phần mềm truyền thống Hoạt động kiểm chứng được thực hiện ít nhất ở cuối mỗi pha trong CSLC Trong quá trình kiểm thử đơn vị ta sử dụng cách cài đặt và kiểm thử “tối ưu nhất” Kiểm thử viên phần mềm phối hợp với tất cả các thành viên trong đội tham gia 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ấu phần xác định nhằm phát triển trong thời gian dài Cài đặt mô hình cấu phần hỗ trợ sự tương tác và kết hợp, từ đó các

kỹ sư có thể tạo các hạ tầng cấu phần phần mềm, đặc tả miền cho các cấu phần

của họ tương tác với các chức năng và hành vi của hệ thống gọi cấu phần 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)

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

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

2.3 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 sử dụng lại cấu phần phần mềm mức ứng dụng là chưa đủ thích hợp Thiếu sót của việc

sử dụng lại xảy ra bởi vì các ứng dụng là quá thô, chúng thiếu hỗ trợ kết hợp, và

hệ điều hành thiếu các chuẩn đặc tả miền Các thiếu sót đó được thể hiện qua một số đặc điểm:

Thiếu tính chất hạt nhân – Lack of granularity – Các ứng dụng là quá thô để

có thể cải thiện việc sử dụng lại Các nhà phát triển ứng dụng thường được yêu cầu thiết kế và cài đặt các chức năng chung chung mà bất kỳ ứng dụng nào cũng

có thể có CBSE tìm ra các nhân tố chung đưa vào các các dịch vụ được cung cấp bởi sự cài đặt mô hình cấu phần hoặc các cấu phần đã được đặt hàng và tích hợp vào hạ tầng cấu phần 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, các cấu phần được làm mịn dần và cho phép sử dụng lại ở mức các ứng dụng thành phần tương tự như tại mức ứng dụng

Thiếu sự hỗ kết hợp – lack of composition support –Trên thực tế, các hệ điều

hành đảm bảo rằng các ứng dụng thực thi hoàn toàn độc lập với nhau Cơ chế như giao tiếp quy trình nội bộ được nói đến là khả năng trao đổi dữ liệu giữa các ứng dụng, nhưng các giao diện ứng dụng thường đặc tả kém và thiếu các chuẩn kết hợp Trong khi các ứng dụng triển khai trong hệ điều hành xác định và sử dụng các dịch vụ của hệ điều hành đó Chúng hiếm khi là đơn vị kết hợp

Thiếu các chuẩn đặc tả miền – (Lack of domain - specific standards) – Các

dịch vụ của một hệ điều hành là quá chung chung không hỗ trợ được các miền ứng dụng đặc tả Ví dụ, một hệ thống đồng bộ cần các dịch vụ khác nhau và giao diện lập trình ứng dụng (APIs-Application programming Interfaces) hơn là 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 các hệ thống phần mềm bằng cách tạo ra các cấu phần có thể sử dụng lại tách biệt thì tốt hơn là các gắn vào ứng dụng Một cách tự nhiên, các cấu phần thô này cần các chuẩn tương tác và kết hợp, cũng như chuẩn hóa các hạ tầng và các dịch vụ Sự tham gia của CBSE là để định nghĩa các mô hình cấu phần theo các chuẩn như vậy và để cung cấp các cài đặt

mô hình cấu phần kết hợp để kích hoạt các cấu phần và các hạ tầng cấu phần được thiết kế, cài đặt, và triển khai

2.3.1 Mô hình cấu phần

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ức thứ hai: Một mô hình cấu phần điều khiển hoạt động chung một tập cấu

phần trong hệ thống trên cơ sở cấu phần giao tiếp và tương tác với nhau Một

mô hình cấu phần tạo nên sự kết hợp bằng việc định nghĩa một chuẩn tương tác

và nâng lên thành giao diện đặc tả tường minh Một cấu phần có thể được tạo từ cấu phần khác hoặc phần tử phần mềm khác bằng cách tạo ra 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 định nghĩa cơ chế cấp phép cho việc tạo các kết nối được tập hợp hoặc tích hợp Theo D‟Souza và Wills (1999) thì “khả năng lắp ghép” chỉ thành công nếu một cấu phần biểu thị được chính xác yêu cầu của cấu phần khác mà nó kết nối tới Quy trình đó cần phải đủ phức tạp để thu được kết quả

đặc tả chính xác Chúng ta sử dụng khái niệm gắn kết cho các cấu phần viết ra

chẳng hạn như bao gói, liên kết tĩnh - động, “plug-and-play”

Mô hình cấu phần có thể định nghĩa các cơ chế tuỳ biến để mô tả cách mà các cấu phần có thể mở rộng mà không có sự hiệu chỉnh Chúng ta coi việc hiệu chỉnh như một dạng cải tiến của tương tác Một mô hình cấu phần có thể cũng định nghĩa các thuộc tính cấu phần bắt buộc như định dạng mã, các chuẩn tài liệu hoặc các giao diện độc lập của nhà sản xuất

[3]Mô hình cấu phần định nghĩa một tập các chuẩn bao gồm: cài đặt cấu phần, đặt tên, khả năng vận hành nội bộ, tuỳ biến, kết hợp, phát triển và triển khai Một mô hình cấu phần cũng định nghĩa chuẩn cho việc triển khai mô hình liên kết các cấu, tập các đối tượng phần mềm thực thi được yêu cầu hỗ trợ thực thi của các cấu phần tuân theo mô hình

Một số các mô hình cấu phần đang được sử dụng hiện nay là mô hình thành phần CORBA của OMG, COM+/DOM, và SUN -javabean, Enterprise JavaBeans của Microsoft Không nhất thiết khi phát triển cấu phần phải tuân theo một chuẩn, nhưng tại một thời điểm không nên có quá nhiều chuẩn

Các phần tử cơ bản của một mô hình cấu phần được Weinreich và Sametinger liệt kê chi tiết - 2001 Hình dưới đây tổng hợp lại các phần tử trong

mô hình cấu phần, nó chỉ ra rằng các phần tử đã được phân loại theo các giao diện cấu phần, các phần tử liên quan đến thông tin mà bạn cần sử dụng đến cấu phần đó trong một 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]

Tài liệu hó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 cấu phần phần mềm toàn cầu các cấu phần được triển khai một cách độc lập và tùy thuộc vào sự kết hợp với bên thứ 3 Thị trường này cần

có các chuẩn Các chuẩn giao tiếp và chuẩn trao đổi dữ liệu giữa các cấu phần khác nhau của các nhà sản xuất cấu phần là rõ ràng Như vậy, một chuẩn hoạt động nội bộ – đôi khi gọi là chuẩn lắp ráp hoặc kết nối – là một phần tử trung tâm trong một mô hình cấu phần Các phần tử cơ bản khác của một mô hình cấu phần là các chuẩn: 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

Một mô hình cấu phần có thể cũng có các chuẩn đặc trưng để mô tả các tính năng đặc tả miền cần thiết trong các ứng dụng Ví dụ, sự kết hợp các cấu phần trong các miền với các hoạt động đang diễn ra đòi hỏi tiếp cận các mô hình chuỗi được chuẩn hoá và các cơ chế đồng bộ Một hệ xử lý phân tán mở đòi hỏi các chuần lời gọi phương thức từ xa, và chuẩn bảo mật Các ứng dụng nghiệp vụ

3 lớp cần các dịch vụ giao dịch được chuẩn hoá và cơ sở dữ liệu APIs Cuối cùng, một mô hình cấu phần với các tài liệu kết hợp (như OLE) cần đặc tả từng

phần, các quan hệ bao hàm và giao diện Các mô hình cấu phần đặc tả miền gọi tới các chức năng đặc biệt trong cài đặt mô hình cấu phần

2.3.1.2 Giao diện, thỏa thuận và ngôn ngữ định nghĩa giao diện

Mục đích của các cấu phần là được sử dụng lại trong phần mềm Hai hình thức sử dụng lại là sử dụng lại hộp trắng và sử dụng lại hộp đen

Sử dụng lại hộp trắng nghĩa là mã nguồn của cấu phần phần là có sẵn đầy đủ

và có thể nghiên cứu, sử dụng lại, lắp ghép hoặc chỉnh sửa Sử dụng lại hộp trắng thể hiện vai trò chính trong các nền tảng hướng đối tượng, đáp ứng sức mạnh kế thừa cho các cài đặt phần mềm sử dụng lại Nhược điểm của sử dụng lại hộp trắng là các khách hàng sử dụng cấu phần có thể thay đổi mã nguồn cấu phần đó nếu có sự thay đổi bên trong chương trình

Sử dụng lại hộp đen dựa trên nguyên tắc che giấu thông tin Người dùng cấu

phần chỉ có thể dựa trên vào các giao diện Các giao diện này là sự mô tả hoặc đặc tả hành vi cấu phần Thông qua các giao diện, các lời gọi cấu phần có thể được thay đổi tiếp tục thỏa mãn yêu cầu định nghĩa Giao diện thể hiện một cách tường minh và qua các công cụ chẳng hạn như bộ biên dịch, có thể kiểm chứng tĩnh khả năng tương thích với các cấu phần client

Một giao diện không phải là phần hợp thành của cấu phần, mà các phần hợp

thành cấu phần là các dịch vụ chẳng hạn như một thoả thuận giữa một cấu phần

với các client của nó Một giao diện đặc tả các dịch vụ yêu cầu từ một client đến cấu phần; cấu phần phải cung cấp một cài đặt các dịch vụ này Thêm vào đó, một giao diện có thể bao gồm các ràng buộc trên các dịch vụ được sử dụng, nó phải được xét trên cả cấu phần và các client của nó Các đặc tả giao diện là phần

tử trung tâm trong một mô hình cấu phần Một mô hình cấu phần định nghĩa cách mà một hành vi cấu phần được mô tả – dựa trên giao diện, các đặc tả khác (phi chức năng) và các tài liệu thích hợp Một mô hình cấu phần định nghĩa các phần tử, mỗi phần tử có thể cấu thành một giao diện Các phần tử của một giao diện gồm có:

 Tên của các phép toán liên quan đến ngữ nghĩa

 Các tham số của chúng

 Kiểu tham số

Các giao diện gồm các ngoại lệ được đưa ra, các điều kiện trước, điều kiện sau phải được đáp ứng khi sử dụng các thao tác riêng lẻ, và các đặc tả từng phần hành vi mong muốn của một giao diện cài đặt cấu phần Nhiều mô hình cấu phần có một ngôn ngữ định nghĩa giao diện (IDL – Interface definition

language) với các giao diện mô tả và các phần tử của nó sử dụng một ký hiệu độc lập cài đặt

Mô hình cấu phần có thể định nghĩa một tập các giao diện đặc tả cần được cài đặt bởi các cấu phần Các giao diện này được sử dụng qua cài đặt mô hình cấu phần cung cấp các dịch vụ đã có sẵn chẳng hạn như các giao dịch hoặc bảo mật

2.3.1.3 Đóng gói và triển khai

Các chuẩn mô hình cấu phần đã được chứng nhận, như các kết nối Internet

băng thông rộng, sẽ làm thay đổi công việc triển khai của phần mềm đóng gói

sẵn Điều này trở nên không cần thiết khi thực hiện gói các hệ thống phần mềm

khổng lồ và các tài liệu đi kèm vào thành 1 sản phẩm dùng ngay được Thêm vào đó, để các cài đặt mô hình cấu phần được tường minh, các cấu phần nhỏ được lắp ghép vào xây dựng ứng dụng Các kết nối internet nhanh hỗ trợ người dùng tải các cấu phần đã đóng gói và tài liệu đi kèm để phát triển các hệ thống phần mềm

Một mô hình cấu phần mô tả cách mà các cấu phần được đóng gói, bởi vậy chúng có thể được triển khai độc lập Một cấu phần được triển khai nghĩa là nó được cài đặt và cấu hình trong một hạ tầng cấu phần Cấu phần được đóng gói thường gồm mã chương trình, dữ liệu cấu hình, các cấu phần khác và các tài nguyên đi kèm Một mô tả triển khai cung cấp thông tin bên trong của gói (hoặc các gói liên quan) và các thông tin khác cần thiết cho quy trình triển khai Chuẩn triển khai đặc tả cấu trúc và ngữ nghĩa cho các mô tả triển khai và nó quy định định dạng các gói Thêm vào nữa, mô hình cấu phần có thể định nghĩa các quy trình triển khai bao gồm cả việc đăng ký cấu phần

2.3.2 Sự cài đặt mô hình cấu phần và các dịch vụ

Nếu một cấu phần thực hiện một công việc cụ thể và cung cấp một giao diện thì bên gọi có thể sử dụng cấu phần đó nếu tuân theo các đặc tả của giao diện cấu phần Các đặc tả cấu phần bao gồm sự định nghĩa chặt chẽ về cú pháp các phương thức, cũng như mô tả về ngữ nghĩa của giao diện Các tiếp cận hiện tại ở mức đăng ký là sử dụng các ngôn ngữ đặc tả giao diện - IDLs cho việc mô tả các giao diện IDLs được định nghĩa bởi CORBA, COM và COM+ là các ví dụ điển hình Việc cài đặt mô hình cấu phần được thiết kế cho tập các phần tử phần mềm

hỗ trợ thực hiện các cấu phần trong một mô hình cấu phần Một mô hình cấu phần có thể được nhúng trong một HĐH nhưng nó sẽ chỉ khiến HĐH trở nên phức tạp thêm, và hạn chế tính ứng dụng của mô hình cấu phần Việc cài đặt mô hình cấu phần tiêu biểu cho một lớp mỏng thực thi ngay trên HĐH Các HĐH đa

nhiệm có thể di chuyển lớp này để đảm bảo khả năng ứng dụng tối đa của mô hình cấu phần

Chuẩn tương tác cho một mô hình cấu phần xác định cách một giao diện phải được đăng ký với sự cài đặt mô hình cấu phần trước khi sử dụng Các giao diện được định nghĩa một cách tường minh bằng việc sử dụng ngôn ngữ định nghĩa giao diện IDL và được lưu trữ lại, kết hợp với cài đặt mô hình cấu phần Chuẩn kết hợp cho một mô hình cấu phần xác định cấu phần đăng ký với sự thực thi

mô hình cấu phần trước khi sử dụng nó Nhà phân phối cài đặt mô hình cấu phần cung cấp các công cụ như chương trình biên dịch IDL nhằm hỗ trợ sự phát triển của các cấu phần Như vậy, sự cài đặt mô hình cấu phần giúp khả năng thực thi các cấu phần tuân theo mô hình Khi nhà sản xuất mô hình cấu phần cũng là nhà thiết kế mô hình cấu phần, mô hình cấu phần đó có thể bị trở thành độc quyền

Một phần quan trọng của mô hình cấu phần là sự chuẩn hoá môi trường chạy thật để hỗ trợ thực thi cấu phần Điều này bao gồm đặc tả giao diện cho cả hai dịch vụ chung và các dịch vụ đặc tả miền tại thời điểm chạy Các dịch vụ chung nhằm hỗ trợ các hệ thống cấu phần trên cơ sở đối tượng bao gồm việc tạo đối

tượng, quản lý chu trình, hỗ trợ gắn kết đối tượng (object-persistence support)

và bản quyền Mô hình cấu phần trong hệ thống phân tán phải định nghĩa các dịch vụ:

 Các dạng giao tiếp khác, chẳng hạn như các hàng đợi thông điệp

 Cảnh báo trên cơ sở sự kiện từ xa

 Các dịch vụ định vị từ xa

 Bảo mật

Mô hình cấu phần hỗ trợ việc xây dựng các hệ thống thông tin đa lớp đặc tả giao diện lập trình ứng dụng (APIs) truy cập dữ liệu và các dịch vụ cho quản lý giao dịch và cân bằng tải

Một thiết kế trên cơ sở cấu phần sẽ phản án quy trình chuẩn hóa đặc trưng đến các dịch vụ đặc tả miền Một ví dụ về một tập các chuẩn được xây dựng trên một mô hình cấu phần chung là kiến trúc quản lý đối tượng (OMA- Object management architechture) OMA được định nghĩa bởi nhóm quản lý đối tượng (OMG – Object management group), một tổ chức phi lợi nhuận với khoảng 800 công nhân có kỹ năng và tay nghề Trọng tâm của mô hình này là kiến trúc CORBA, một chuẩn vận hành cho các ứng dụng trên cơ sở đối tượng phân tán

hỗ trợ các ngôn ngữ cài đặt khác nhau

Các mô hình cấu phần nổi tiếng khác như COM của Microsoft và JavaBean của Sun định nghĩa các dịch vụ giống nhau có ích trong các hệ thống đa miền Tất cả

các nhà cung ứng cài đặt mô hình cấu phần cũng đang phát triển các tương tác đặc tả miền và các chuẩn kết hợp

Quản lý hệ thống các tài liệu thống nhất

Đồng bộ Thông tin liên lạc

Tự động hóa quy trình Tài chính

Chăm sóc dịch vụ

Tổng quát

Hiện nay, một số HĐH như Microsoft Windows đã kết hợp các cài đặt mô hình cấu phần Như vậy, các hệ điều hành có thể tiến hành phục vụ trực tiếp các cài đặt mô hình cấu phần trên CBSE

Như thế ta có một số các tổng kết sau:

Các HĐH cung cấp:

 Sự trừu tượng dưới góc độ phần cứng (hạ tầng)

 Môi trường thực thi

 Các dịch vụ nền cho ứng dụng

Các mô hình cấu phần: Mô hình cấu phần định nghĩa các chuẩn đặt tên, siêu

dữ liệu, đặc tả hành vi cấu phần, sự cài đặt cấu phần, sự vận hành trong cấu phần, sự tuỳ biến, sự kết hợp và triển khai

Cài đặt mô hình cấu phần: cài đặt mô hình cấu phần là dựa trên từng mô hình cấu phần riêng lẻ Nó cung cấp:

 Môi trường chạy

 Các dịch vụ cơ bản

 Các dịch vụ ngang có tác dụng trong các miền đa nhiệm

 Dịch vụ dọc cung cấp chức năng cho từng miền trong các cấu phần phần mềm

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

Ngôn ngữ Mô hình thống nhất (UML-Unified modeling language) là chuẩn ngôn ngữ với mô hình chủ thể thế giới thứ ba Hiện nay UML vẫn là yếu tố chuẩn cho mô hình hoá phần mềm Có rất nhiều lý do người ta ứng dụng UML trong lĩnh vực phần mềm

2.4.1 Mục tiêu của UML

Có thể nói rằng mô hình là một sự đơn giản hoá hiện thực Mô hình được xây dựng để chúng ta dễ dàng hiểu và hiểu tốt hơn hệ thống cần xây dựng [6]

Nói tóm lại, thông qua mô hình hóa giúp ta mô tả được mặt bản chất của một vấn đề hoặc một cấu trúc phức tạp bằng cách loại bỏ những chi tiết không quan trọng, khiến cho bài toán trở nên dễ hiểu và dễ nắm bắt 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ễ thay đổi (changeable)

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

Mục đích của UML là cho phép người dùng xác định được mô hình của hệ thống Phần quan trọng của mô hình người dùng là định nghĩa các ngữ nghĩa của

hệ thống đang được phát triển 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 được xây dựng với mục đích là:

 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

hiện đúng đắn, mô hình này có thể kiểm chứng được qua phân tích hoặc thực hiện và dùng để tạo ra các mức độ mã nguồn để triển khai hệ thống Code có thể

tự động tạo ra nếu ta dùng các công cụ như Rhapsody, hoặc công cụ tự viết ra Việc mã code sinh tự động có rất nhiều ưu điểm như giảm nguồn lực và bảo trì tính ổn định giữa mô hình UML và mã lệnh, cả hai đều dùng để 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:

 Trước hết, UML có một mô hình ngữ nghĩa nền tảng được định nghĩa rõ ràng, gọi là siêu mô hình UML Mô hình ngữ nghĩa này vừa rộng (bao quát hầu hết các lĩnh vực cần thiết tiêu chuẩn kỹ thuật và thiết kế của

hệ thống), vừa sâu (nghĩa là nó có thể tạo ra các mô hình có thể triển khai được hoặc có thể sử dụng để tạo ra các mức độ mã nguồn phục vụ cho việc chuyển đổi ngôn ngữ Lập trình viên có thể dễ dàng có mô hình bất kỳ của

Ngày nay UML được sử dụng cho các mô hình và các hệ thống xây dựng với rất nhiều phạm vi từ đơn giản với thời gian phù hợp và nguồn lực quản lý ứng với các hệ thống nhúng và hệ thống thời gian thực Điều đó có ý nghĩa khi các lập trình viên không dùng UML trong các hệ thống của họ, hệ thống sẽ gặp phải những khó khăn nhất định

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

UML có thể được sử dụng trong nhiều giai đoạn, từ phát triển, thiết kế cho tới thực thi và bảo trì Vì mục đích chính của ngôn ngữ này là dùng các biểu đồ hướng đối tượng để mô tả hệ thống, nên miền ứng dụng của UML bao gồm nhiều loại hệ thống khác nhau như: 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, 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ộ: use cases thể hiện các yêu cầu của người dùng Phần

miêu tả use case xác định các yêu cầu, phần diagram thể hiện mối quan hệ và giao tiếp với hệ thống

Phân tích: Mục đích chính của giai đọan này là trừu tượng hóa và tìm hiểu

các cơ cấu có trong phạm vi bài toán Class diagrams trên bình diện trừu tượng

hóa các thực thể ngoài đời thực được sử dụng để làm rõ sự tồn tại cũng như mối

quan hệ của chúng Chỉ những lớp (class) nằm trong phạm vi bài toán mới đáng

quan tâm

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 mô hình hóa chi tiết để cung cấp hạ tầng kỹ thuật như giao diện,

nền tảng cho database, … Kết quả phần Design là các đặc tả chi tiết cho giai

đoạn 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 (integration diagrams & collaboration diagrams) :

kiểm tra tích hợp là kiểm tra kết hợp các cấu phần với các lớp để xem chúng hoạt động với nhau có đúng khô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

 Kiểm thử chấp nhận: Kiểm tra tính chấp nhận được của hệ thống,

thường được thực hiện bởi khách hàng, việc kiểm tra này thực hiện tương

tự như kiểm tra hệ thống

2.4.3 Các công cụ xây dựng UML

Rất nhiều công cụ trong thực tế chỉ thông minh hơn các chương trình vẽ một chút, sử dụng một vài quy chế kiểm tra tính nhất quán hoặc một vài kiến thức về phương pháp và ngôn ngữ mô hình hóa

Cùng với sự ra đời của ngôn ngữ UML, các nhà cung cấp công cụ mô hình hóa giờ đây có thể dành nhiều thời gian hơn cho việc nâng cấp công cụ

Mặc dù đã có một vài bước tiến nhất định và nhiều công cụ đã được sử dụng

để nhằm mục đích hỗ trợ xây dựng UML như Rational Rose, GDPro, Visio,

…,nhưng thị trường vẫn còn không ít công cụ chưa được gọt giũa, vẫn còn chứa lỗi hoặc những điểm bất hợp lý, kể cả những vấn đề đơn giản như copy và dán Những công cụ này còn có hạn chế ở một số phương diện nhất định

Tuy nhiên, một công cụ mô hình hóa hiện đại cũng cần phải đáp ứng được các chức năng sau:

Vẽ biểu đồ: Cần phải tạo điều kiện dễ dàng vẽ ra các biểu đồ trong ngôn ngữ

mô hình hóa Công cụ cần phải đủ khả năng thông minh để hiểu mục đích của các biểu đồ và biết được những ngữ nghĩa cũng như các quy tắc đơn giản, đủ để

nó có thể cảnh báo hoặc ngăn chặn việc sử dụng không thích hợp các phần tử

mô hình

Hoạt động như một kho: công cụ cần phải hỗ trợ một kho trung tâm để tất

cả các thông tin về mô hình được lưu trữ trong cùng một chỗ Nếu ví dụ tên của một lớp bị thay đổi trong một biểu đồ, thì sự thay đổi này cần phải xảy ra trong tất cả các biểu đồ khác có sử dụng lớp này

Hỗ trợ định hướng: công cụ cần phải tạo điều kiện dễ dàng cho người dùng

định hướng và chuyển dịch trong mô hình để theo dõi một phần tử từ biểu đồ này sang biểu đồ khác, hoặc để mở rộng sự mô tả của một phần tử

Hỗ trợ nhiều người dùng: Công cụ cần hỗ trợ cho nhiều người dùng, và tạo

điều kiện cho họ cùng làm việc với một mô hình mà không ngăn chặn hoặc quấy phá lẫn nhau

Tự động tạo code: một công cụ cao cấp cần phải có khả năng tạo ra code,

nơi tất cả các thông tin trong mô hình được chuyển tải thành các khung code (code skeletons), được sử dụng làm nền tảng cho giai đoạn xây dựng chương trình

Tái tạo mô hình: Một công cụ cao cấp cần phải có khả năng đọc những

thành phần code đang tồn tại và từ đó sản xuất ra mô hình Từ đó suy ra, một mô hình có thể được làm từ những dòng code đã tồn tại; hoặc một nhà phát triển có thể dễ dàng chuyển đi chuyển về giữa công việc mô hình hóa và công việc lập trình

Tích hợp với các công cụ khác: một công cụ cần phải có khả năng tích hợp

với những công cụ khác, với cả việc phát triển môi trường, ví dụ như các trình soạn thảo, chương trình dịch, chương trình tìm lỗi cũng như các công cụ của doanh nghiệp khác như công cụ quản trị cấu hình, hệ thống theo dõi các phiên bản

Bao quát mô hình ở tất cả các mức độ trừu tượng hóa khác nhau: công

cụ cần phải dễ chuyển tải từ lời miêu tả ở cấp trừu tượng hóa cao nhất của hệ thống (tức là ở dạng một lượng các gói khác nhau) đi xuống cho tới cấp của những dòng code thật sự Sau đó, để truy xuất những dòng lệnh code cho một thủ tục cụ thể nào đó trong một lớp nào đó, bạn có thể chỉ cần nhấp chuột vào tên của thủ tục đó trong một biểu đồ

Trao đổi mô hình: Một mô hình hay một biểu đồ của một mô hình nào đó

cần phải có khả năng được xuất ra từ một công cụ này rồi nhập vào một công cụ khác, giống như những dòng lệnh code được sản sinh trong một công cụ này có thể được sử dụng trong một công cụ khác Nguyên tắc trao đổi đó cần phải được

áp dụng cho các mô hình trong một ngôn ngữ mô hình hóa được định nghĩa chính xác

Như vậy, ta đặt ra câu hỏi là liệu có thể kiểm thử dựa trên các lược đồ UML? Tạo các lược đồ UML có rẻ hơn và dễ kiểm thử hơn cái phần mềm mà nó biểu diễn? Trong cả hai tình huống, câu trả lời không bao giờ rõ ràng Không có phương pháp chắc chắn nào để kiểm tra các lược đồ UML Chúng ta có thể nhìn chúng, định lượng chúng, áp dụng các nguyên tắc thiết kế và các mẫu thiết kế lên chúng, nhưng kết quả của việc đánh giá chúng vẫn rất chủ quan Vẽ lược đồ UML thì dễ hơn là viết phần mềm, nhưng với hệ số không lớn Thật vậy, thay đổi mã nguồn dễ hơn rất rất nhiều lần so với việc thay đổi một lược đồ Tại sao

ta nên sử dụng các công cụ UML? hay dùng công cụ xây dựng UML có phải là cách hợp lý không? Ta sẽ không sử dụng một mô hình UML nếu như dùng nó là không hợp lý Tuy nhiên, những lập luận trên nhằm giải thích rằng UML rất dễ

bị dùng sai mục đích Chúng ta sử dụng UML khi chúng ta có một thứ gì đó mà chúng ta dứt khoát phải kiểm thử nó, và khi dùng UML để kiểm thử thì rẻ hơn là dùng mã nguồn để kiểm thử nó Ví dụ, nói rằng tôi có một ý tưởng cho một thiết

kế nào đó Tôi muốn kiểm tra rằng liệu những thành viên trong nhóm của tôi có cho rằng đấy là một ý tưởng đúng đắn không Vì vậy tôi vẽ lược đồ UML lên bảng và hỏi thành viên trong nhóm để nhận phản hồi

Sau khi các thành viên đã thông qua ý tưởng trình bày (lược đồ UML), đội phát triển tiến hành thiết kế, lập trình và kiểm thử Kiểm thử là khâu không thể thiếu trong quy trình phát triển phần mềm

2.5 Lý thuyết kiểm thử

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

Ngày nay, hầu hết mọi người đều có kiến thức về hệ thống phần mềm Ta làm quen với chúng mọi nơi: ở nhà, trong công việc, khi đi mua sắm, và trong các hệ thống giao tiếp rộng khắp Càng ngày khái niệm phần mềm càng đi vào cuộc sống của chúng ta Ta sử dụng phần mềm vào các công việc như nghiệp vụ ngân hàng, các sản phẩm phục vụ cho cuộc sống hàng ngày như ô tô, máy rửa bát Tuy nhiên, trong lĩnh vực phần mềm thường xuất hiện một số rủi ro chẳng hạn như: lỗi hóa đơn với giao dịch mua bán, sự chậm trễ chờ xử lý thẻ tín dụng với giao dịch ngân hàng, hay một trang web không được tải lên internet

Không phải tất cả các hệ thống phần mềm đều có cùng một mức rủi ro và không phải tất cả các vấn đề có chung một dạng ảnh hưởng khi rủi ro xảy ra Rủi

ro là một cái gì đó chưa xảy ra và cũng có thể là không bao giờ xảy ra; nó là vấn

đề tiềm năng Ta lo lắng về các vấn đề có khả năng xảy ra, khi một rủi ro nào đó xảy ra chúng ta sẽ bị một tác động ngược trở lại Khi chúng ta nói đến rủi ro, chúng ta phải xem xét về cách mà nó xảy ra và các ảnh hưởng của nó

Một số vấn đề chúng ta gặp phải là ta sử dụng phần mềm rất thường xuyên, nhưng có thể chi phí cho nó là rất cao và lỗi phần mềm gây ra những thiệt hại như tốn tiền, thời gian và ảnh hưởng đến danh tiếng kinh doanh, thậm chí có một số gây tác hại lớn đến cá nhân như bị thương hoặc chết người

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

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

 Nếu một chương trình phần mềm tính toán sai gây ra lỗi nghiêm trọng đến chất lượng phần mềm, các ảnh hưởng của nó có thể là: giả sử dấu phẩy động đặt sai vị trí bởi vậy mà tỷ lệ trong ứng dụng thay đổi lên gấp cả chục lần

Vì thế kiểm thử là bước không thể thiếu trong quy trình sản xuất phần mềm,

kiểm thử giúp cho phần mềm đạt chất lượng, tránh các rủi ro không cần thiết trong sản phẩm

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?

Ta biết rằng bất kỳ ai bao gồm cả lập trình viên và nhân viên kiểm thử, có thể gây ra các sai sót Các sai sót này sẽ làm sản sinh ra lỗi trong mã chương trình, trong hệ thống hoặc trong một tài liệu nào đó Nếu lỗi phát sinh từ trong code dẫn đến việc hệ thống có thể có khả năng bị thất bại Bởi thế các sai sót chúng ta gây ra là một phần để lại kết quả trong các sản phẩm mà ta chịu trách nhiệm Các sai sót của chúng ta có thể là nghiêm trọng bởi vì các hệ thống phần mềm và các dự án là phức tạp Nhiều sản phẩm chuyển tiếp và sản phẩm cuối cùng được dựng lên trong một dự án, con người ta chắc hẳn sẽ gây ra các sai lầm, thiếu sót trong toàn bộ các hoạt động xây dựng Một số sai sót trong số đó

có thể được loại bỏ trong quá trình xây dựng, nhưng người ta khó tìm ra lỗi của

họ trong khi xây dựng sản phẩm Lỗi trong phần mềm, các hệ thống hoặc các tài liệu có thể là nguyên nhân gây ra các hỏng hóc Tuy vậy, không phải tất cả lỗi đều gây ra các hỏng hóc

Khả năng của con người là khá phức tạp, khi ta thiếu kinh nghiệm, không nhận được các thông tin đúng, thiếu hiểu biết, hoặc nếu khi không cẩn thận, mệt mỏi, hoặc cảm thấy không hài lòng Tất cả các nhân tố này ảnh hưởng đến khả năng của chúng ta để đưa ra các quyết định nhạy cảm – não của chúng ta cũng không có thông tin hoặc việc xử lý nó không đủ nhanh

Hơn nữa, chúng ta lại gặp thêm các lỗi liên quan đến sự phức tạp kỹ thuật, các vấn đề nghiệp vụ, sự phức tạp của các quy trình nghiệp vụ, code hoặc hạ tầng, sự thay đổi kỹ thuật hoặc rất nhiều các tương tác hệ thống

Không chỉ các lỗi gây nên sự hỏng hóc Các hỏng hóc có thể cũng có nguyên nhân bởi các điều kiện môi trường: ví dụ như một vụ nổ bức xạ, từ trường mạnh, các lĩnh vực liên quan đến điệu tử, hoặc sự ô nhiễm có thể là nguyên nhân gây các lỗi trong phần cứng hoặc phần vi xử lý Các lỗi này có thể ngăn cản, hoặc thay đổi sự thực hiện của phần mềm Các sai sót có thể cũng xuất hiện do sai lầm của người tương tác hệ thống phần mềm, có thể là giá trị đầu vào sai hoặc

do kết quả đầu ra bị sai

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ỏng hóc bên trong

 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ác lỗi chương trình cần được sửa

Yêu cầu 2

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

Lỗi trong thiết kế

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 số 1 được thực hiện đúng – chúng ta hiểu yêu cầu khách hàng, thiết

kế đúng đáp ứng đầy đủ yêu cầu, xây dựng đúng theo thiết kế, và bởi vậy phát triển các yêu cầu đó theo đúng thuộc tính; chức năng Sản phẩm làm ra sẽ đáp ứng được những giả định và các thuộc tính phi chức năng, bởi vậy yêu cầu thực hiện được đáp ứng, sản phẩm làm ra là thân thiện, dễ hiểu cho người dùng

Với yêu cầu số 2 được phát triển bình thường cho tận đến giai đoạn code, khi

ta gây ra một số sai sót, và các lỗi xuất hiện Các sai sót này để lại dấu vết và

được sửa khi tiến hành kiểm thử, bởi thế chúng ta có thể thấy sản phẩm trước khi tiến hành kiểm thử sẽ không đáp ứng đặc tả thiết kế

Các lỗi nói đến trong yêu cầu số 3 là khó liên hệ hơn; chúng ta xây dựng theo đúng những gì mà chúng ta đã nói, nhưng thật không may mắn người thiết kế gây ra một số sai sót, bởi vậy lỗi đó tiếp tục tồn tại tại khâu trong phát triển Nếu chúng ta không kiểm tra lại các yêu cầu định nghĩa, ta sẽ không thể tìm ra những lỗi này trong quá trình kiểm thử Khi ta phát hiện ra lỗi thì chúng sẽ trở nên khó sửa, bởi vì khi đó thiết kế sẽ phải thay đổi

Các lỗi trong yêu cầu số 4 được đưa ra khi định nghĩa các yêu cầu; sản phẩm được thiết kế và xây dựng đáp ứng các yêu cầu định nghĩa Nếu khi kiểm tra ta thấy sản phẩm đã đáp ứng yêu cầu và thiết kế hay chưa, quá trình kiểm thử là thành công Nhưng mặt khác, sản phẩm đó có thể bị loại bởi khách hàng hoặc người dùng cuối Các lỗi này được liệt kê khi khách hàng thực hiện kiểm thử nghiệm thu hoặc đưa vào sử dụng Như vậy chi phí phát hiện lỗi ở bước này là rất cao Thực tế, các lỗi xuất phát từ bước tìm hiểu yêu cầu và thiết kế là không hiếm; qua việc đánh giá hàng ngàn dự án, người ta đã chỉ ra rằng các lỗi trong các yêu cầu và thiết kế chiếm một nửa trong tổng số các lỗi dự án

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

Tại thời điểm xem xét các ảnh hưởng của việc phát sinh các hỏng hóc từ lỗi,

ta cần phải xem xét các ảnh hưởng khi tìm ra các lỗi này Chi phí cho việc tìm

và sửa lỗi được tính đến dựa trên vòng đời của nó Chẳng hạn, nếu bạn vá được một lỗ hổng trên ống tay của bạn bây giờ khi nó còn nhỏ, điều đó rất dễ làm, nhưng nếu bạn để lại đó, nó sẽ hỏng tệ hơn và cần nhiều mũi vá hơn mới sửa được

Nếu ta liên hệ lại theo một chuỗi các cái đã đề cập từ trước đến hình dưới đây, ta thấy rằng, nếu một sai sót gây ra và kết quả là lỗi được tìm thấy tại giai đoạn đó thì liên quan đến việc chi phí tìm và sửa lỗi là rẻ Ta thấy sự tăng chi phí sửa khi thời gian các lỗi để càng lâu mới phát hiện được, bạn sẽ thấy được các bằng chứng hiệu quả kinh tế của việc kiểm thử và các hoạt động đảm bảo chất lượng khác Đặc tả có thể được sửa hoặc đề cập ngược trở lại Giống như nếu một sai sót gây ra và kết quả là nó được tìm thấy ngay trong giai đoạn thiết

kế, thì thiết kế có thể được sửa, và như thế chi phí để sửa chữa sai lầm là ít hơn nếu nó được phát hiện ở các giai đoạn sau

Hình 4 Chi phí sửa lỗi qua các giai đoạn phát triển [2]

Chi phí tìm và sửa lỗi tăng theo

đó, ta sẽ phải thực hiện lại các công việc đặc tả, thiết kế; và một lỗi trong các yêu cầu có thể bị nhân lên ở nhiều nơi trong thiết kế và trong code; và tất cả các công việc kiểm thử được tiến hành theo từng điểm sẽ cần được lặp lại để phần mềm đạt đến mức ổn định chấp nhận được

Thường các lỗi được phát hiện ra ở giai đoạn rất muộn, phụ thuộc vào độ nghiêm trọng của chúng, bởi thế chi phí sửa nó là quá cao Cũng vậy, nếu phần mềm đó được chuyển giao và đáp ứng được đặc tả, đôi khi nó sẽ không được chấp nhận nếu đặc tả là sai Nhóm dự án có thể đã chuyển giao đúng những gì

họ được yêu cầu, nhưng lại không phải những gì người dùng mong muốn Trong một số trường hợp, những lỗi đó là quá nghiêm trọng, vì thế hệ thống phải được cài đặt lại từ đầu

2.5.3 Vai trò của kiểm thử trong phát triển phần mềm

Ta thấy rằng số lượng lớn các sai sót có thể là nguyên nhân gây ra một lỗi ở bất kỳ giai đoạn nào trong vòng đời phát triển phần mềm và, kết quả của sai sót

đó có thể nhỏ cũng có thể là rất nghiêm trọng Kiểm thử một cách chặt chẽ là cần thiết trong khi phát triển và bảo trì hệ thống nhằm nhận dạng lỗi, giảm thiểu những hỏng hóc trong môi trường vận hành và tăng chất lượng của hệ thống vận hành Điều này bao gồm cả việc tìm kiếm các sai sót có khả năng xảy ra như khi

nhập dữ liệu đầu vào hoặc đưa ra kết quả dữ liệu đầu ra, và tìm kiếm các điểm yếu của hệ thống trong trường hợp bị tấn công và phá hoại Thực hiện kiểm thử giúp chúng ta cải thiện dần chất lượng sản phẩm và dịch vụ, đó chỉ là một trong những phương thức kiểm chứng và xác thực được áp dụng cho sản phẩm Một trong các phương thức kiểm chứng khác có thể được sử dụng kiểm tra công việc, một số trong số chúng được thực hiện bởi chính tác giả, và một số được thực hiện bởi các đối tượng khác nhằm có được một hướng nhìn độc lập

Chúng ta có lẽ cũng được yêu cầu để tiến hành kiểm thử phần mềm nhằm đạt được các yêu cầu về giao kèo, yêu cầu hợp pháp, hoặc các chuẩn đặc tả công nghiệp Các chuẩn này có thể đặc tả các kỹ thuật chúng ta sử dụng, hoặc tỷ lệ

mã chương trình phải được sử dụng

2.5.3.1 Kiểm thử bao nhiêu là đủ?

Vậy chúng ta nên tiến hành kiểm thử bao nhiêu? Ta có được lựa chọn kiểm thử một thứ, tất cả mọi thứ, không kiểm thử gì hay chỉ tiến hành kiểm thử một số? Câu trả lời lập tức là “Mọi thứ phải được kiểm thử” Ta không muốn sử dụng phần mềm mà chưa qua tiến hành kiểm thử Điều này có nghĩa rằng chúng

ta phải thử nghiệm mọi khía cạnh của một hệ thống phần mềm khi tiến hành công việc kiểm thử Chúng ta cần phải cân nhắc xem phải làm gì, hay có thể làm

gì để hoàn thành công việc đó

Như vậy ta cần tiến hành công việc kiểm thử một cách thấu đáo bao nhiêu là đủ? Ví dụ, có bao nhiêu trường hợp sẽ cần phải tiến hành kiểm thử cho một trường số - một ký tự? Câu hỏi là, „Bạn phải đưa ra các tình huống gì để hoàn thành công việc kiểm thử này?‟ Có 10 khả năng các giá trị số đúng, tất cả các giá trị sai sẽ bị loại bỏ Có 26 ký tự viết hoa, 26 ký tự viết thường, ít nhất 6 ký tự đặc biệt và các ký tự kết thúc câu, ký tự trắng Như thế có ít nhất 68 trường hợp

để kiểm tra trường số-một ký tự

Thực tế ta không thể thực hiện kiểm thử quá nhiều như vậy Các hệ thống thực tế có nhiều hơn một trường nhập liệu, và các trường có độ dài khác nhau Các trường hợp này sẽ cần thực thi trên các môi trường khác nhau Nếu ta lấy ví

dụ, một màn hình nhập có 15 trường giá trị đầu vào, mỗi trường có 5 khả năng kiểm thử, vậy để kết hợp kiểm thử tất cả các giá trị đầu vào là đúng, ta sẽ cần

515 trường hợp! Điều đó có vẻ không hợp lý để thực hiện được số lượng các ca kiểm thử là quá lớn

Áp lực trên một dự án bao gồm thời gian, ngân sách, sự cần thiết để đưa ra một giải pháp kỹ thuật đáp ứng được mong muốn của khách hàng Khách hàng

và các nhà quản lý dự án sẽ thực hiện trực tiếp kiểm thử Công việc này sẽ ngăn

chặn được các hỏng hóc sau khi bàn giao, góp phần vào chi phí sản phẩm Công việc kiểm tra là hoàn thành - nếu nó đơn giản là những gì khách hàng yêu cầu – hay những gì khác hàng không chấp nhận

Chúng ta tiếp cận công việc kiểm thử bằng cách sắp xếp công việc kiểm thử

cần làm, đưa ra các rủi ro về phía khách hàng, stackholders, dự án và phần mềm

Đánh giá và quản lý rủi ro là một trong những hoạt động quan trọng của bất kỳ

dự án nào, là hoạt động cơ bản Quyết định xem kiểm thử bao nhiêu là đủ nên được tính toán dựa trên mức của rủi ro, bao gồm cả rủi ro về kỹ thuật và nghiệp

vụ liên quan đến sản phẩm và ràng buộc dự án như thời gian và ngân sách Kiểm thử cung cấp thông tin tin cậy cho các stakeholders, để thông báo các quyết định bàn giao phần mềm hoặc hệ thống mà ta kiểm thử, chuyển đến bước phát triển tiếp theo hoặc bàn giao cho khách hàng Nguồn lực đưa vào đảm bảo chất lượng và các hoạt động kiểm thử cần tính toán đến các rủi ro và các chi phí được kết hợp với dự án Do sự hạn chế của ngân sách, thời gian và trong khi kiểm thử chúng ta cần quyết định công việc kiểm thử dựa trên các rủi ro

2.5.3.2 Cần kiểm thử những gì?

Ta bắt đầu sẽ tìm hiểu về kiểm thử dưới dạng quy trình, sau đó là các đối tượng của quy trình kiểm thử

- Quy trình - Kiểm thử giống một quy trình hơn một hoạt động đơn lẻ -

trên đó là một chuỗi các hoạt động

- Tất cả các hoạt động theo chu trình - Lỗi được phát hiện càng muộn

trong vòng đời tìm lỗi thì chi phí sửa lỗi càng cao Nếu ta có thể tìm và sửa các lỗi ngay ở giai đoạn tìm hiểu yêu cầu, sẽ giúp cho quy hiệu quả kinh tế của sản phẩm phần mềm được nâng cao Chúng ta sẽ xây dựng được phần mềm đúng đắn chi phí thấp Bởi vậy, quy trình kiểm thử được thiết kế ngay

từ đầu có thể ngăn chặn được các lỗi sinh ra ở giai đoạn code về sau Đôi khi

ta liên hệ điều này với việc „kiểm chứng lại cơ sở kiểm thử thông qua thiết

kế ca kiểm thử‟ Cơ sở việc kiểm thử dựa trên các tài liệu như đặc tả yêu cầu, đặc tả thiết kết

- Cả kiểm thử tĩnh và động – Các ca kiểm thử bằng việc thực thi code để

chứng minh kết quả của các bước chạy kiểm thử (thường gọi là kiểm thử động), chúng ta cũng có thể tìm ra các sai sót mà không chay đoạn code nào - cách kiểm thử này gọi là kiểm thử tĩnh Việc kiểm thử tĩnh bao gồm xem xét tài liệu (gồm cả mã nguồn) và phân tích tĩnh Đây là lợi ích và hiệu quả chi phí của kiểm thử

- Lập kế hoạch – Các hoạt động diễn ra trước và sau khi thực thi kiểm

thử Chúng ta cần quản lý công việc kiểm thử; Ví dụ, ta lập kế hoạch cho những công việc cần làm; điều khiển các hoạt động kiểm thử; báo cáo tiến trình kiểm thử và trạng thái phần mềm thông qua việc kiểm thử; và ta kết thúc kiểm thử khi hoàn thành một giai đoạn

- Sự chuẩn bị - Chúng ta cần chọn cái cần kiểm thử và ta sẽ làm điều đó

bằng cách lựa chọn điều kiện kiểm thử, thiết kế các tình huống kiểm thử

- Đánh giá – Ngay khi thực hiện các công việc kiểm thử, chúng ta phải

kiểm tra kết quả và đánh giá phần mềm dưới góc độ kiểm thử và điều kiện hoàn thành giúp ta quyết định xem có kết thúc công việc kiểm thử hay không

và sản phẩm phần mềm có vượt qua được công đoạn kiểm thử chưa

- Dò lỗi – Chúng ta thường nghĩ về kiểm thử phần mềm với ý nghĩa là

dò tìm những thiếu sót hoặc nhược điểm trong khi vận hành bắt nguồn từ nguyên nhân không tương thích Việc tìm ra những nhược điểm giúp ta hiểu được các rủi ro kết hợp trong phần mềm đưa vào việc sử dụng hệ thống, đóng lỗi cải thiện chất lượng sản phẩm Phân tích được nguyên nhân gốc rễ của lỗi phát sinh cũng giúp ta cải thiện nâng cấp các quy trình phát triển và ít gây lỗi hơn trong công việc tiếp theo

Đây là định nghĩa phù hợp của kiểm thử ở bất kỳ mức nào, từ kiểm thử đơn

vị đến kiểm thử chấp nhận, nó đem lại cho chúng ta dưới nhiều mục tiêu khác nhau, và được lưu lại trong các báo cáo kiểm thử

2.5.3.3 Khi nào mục tiêu kiểm thử được đáp ứng?

Chúng ta có thể sử dụng cả hai hình thức kiểm thử động và tĩnh để đạt được các mục tiêu kiểm thử Cả hai đều cung cấp thông tin để cải thiện hệ thống được kiểm thử, các quy trình phát triển và kiểm thử Kiểm thử nhằm các mục tiêu:

Trong “kiểm thử phát triển” này (bao gồm kiểm thử từng cấu phần riêng lẻ, tích hợp và kiểm thử hệ thống), mục tiêu chính là để tìm ra các nguyên nhân gây

hỏng hóc, các khả năng phát hiện lỗi và sửa lỗi Tiếp theo, những người dùng phần mềm có thể tiến hành kiểm thử chấp nhận để xác nhận rằng hệ thống làm việc theo như mong đợi, đáp tứng được đầy đủ các yêu cầu

Sửa lỗi không phải là mục tiêu kiểm thử hay đưa ra kết quả mong muốn Đôi khi, ta chỉ muốn tập hợp thông tin và đo được chất lượng phần mềm Có một số yếu tố đo phần mềm như thời gian giữa hai lần lỗi gặp liên tiếp để đánh giá khả năng tin cậy, hoặc sự đánh giá mật độ lỗi phần mềm từ đó xác định được rủi ro khi bàn giao sản phẩm

2.5.3.4 Các yếu tố cơ bản trong kiểm thử [2]

Bảng 2: Các yếu tố cơ bản trong kiểm thử

1 Kiểm thử chỉ ra sự hiện diện

của lỗi

Kiểm thử chỉ ra rằng sản phẩm có các lỗi, nhưng không thể chứng minh được

là sản phẩm đó là không có lỗi Kiểm thử làm giảm khả năng còn lỗi phần mềm, nhưng khi không tìm thấy lỗi thì cũng không có nghĩa là ta kết luận được phần mềm là chạy đúng

2 Kiểm thử một cách thấu đáo

là không thể

Kiểm thử mọi thứ (kết hợp đầu vào và các tiền điều kiện) là hoàn toàn không khả thi với các trường hợp tầm thường Thay vì việc kiểm thử thấu đáo tất cả ta

sẽ tập trung nguồn lực vào việc xem xét các rủi ro, và mức độ ưu tiên

3 Kiểm thử sớm

Các hoạt động kiểm thử hệ thống hoặc vòng đời phát triển phần mềm cần được bắt đầu ngay khi có thể, và tập trung vào mục tiêu đã định nghĩa

4 Phân vùng lỗi

Một số các module chứa hầu hết các lỗi phát hiện được trong khi tiến hành kiểm thử, hoặc chỉ ra các lỗi thường xuyên nhất

5 Loại trừ các lỗi lặp

Nếu các lỗi giống nhau lặp đi lặp lại nhiều lần, như vậy người kiểm thử sẽ không tập trung tìm được các lỗi mới Để phát hiện "loại trừ các lỗi lặp" thì các trường hợp kiểm thử cần được xem xét

thường xuyên và hiệu chỉnh lại, các kiểm thử mới phải được viết ra và thực hành với các phần khác nhau trong phần mềm hoặc hệ thống để tìm các lỗi tiềm năng

6 Kiểm thử phụ thuộc ngữ

cảnh

Kiểm thử được tiến hành khác nhau trong các hoàn cảnh khác nhau Ví dụ kiểm thử cho các phần mềm được bảo mật khác với việc kiểm thử các trang thương mại

7 Thiếu các lỗi giả định

Tìm và sửa lỗi không giúp gì nếu việc xây dựng hệ thống là không tiện lợi, không đáp ứng những gì người dùng cần

và mong đợi