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

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 dược yêu cầu khách hàng với các mong muốn họ đưa ra Khái niệm

ĐẠI HỌC QUỐC GIÁ HÀ NỘI TRƯỜNG ĐẠT HỌC CÔNG NGHỊ:

'VĂN THỊ HỚNG PHÚC

NGHIÊN CỨU KỸ THUẬT KIEM THU PHAN MEM

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

LUẬN VĂN THẠC SĨ

Hà Nội - 2009

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

11 - Giới thiệu nhiệm vụ chính của để tả - - m"

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

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

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

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

2.1.2 Chuẩn kết hop [3],

2.3 Vòng dời phát lriễn thần miền 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

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

2.3.2 Sự cải dit mé hinh cau phan và các dich vu

2.4 UML, trong phải triển phần môm

2.4.1 Mục tiêu oda UML

2.4.2 Vai trò, vị trí cia ce luge dé UML trong vòng dn

2.4.3 Các công cụ xay dung UME on

3.5 Lý thuyết kiêm thử

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

2.5.2 Nguyễn nhân gây lỗi phản mềm “ -

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

Chương 3: Kiểm thử trên cơ sở các mé hinh UML

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

32 UML và kiểm tht

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

3.4 Cac khia canh kidm thar

3.5 Mô hình kiểm thử trong phân mềm edu phan [5] 30

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

3.4.2 Mô hình hành vi

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

3.4.4 Các quan hệ về trong tác đữ liệu

3.6 UML trong pha kiểm thứ tích hợp "

3.5.1 Mô hình áp đụng cho kiếm thử tich hợp phần mém cau pl

3.5.2 Các tiếp cân kiểm thứ tích hop trén cơ sở UML

Chương 4: Thục nghiệm kiểm thử phản mệm

4.1 Sử dìmg edu phin Tex! trong Fava

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

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

4.4.1 Xây dụng luông nghiệp vụ trên cơ sở cách tiếp cận ruỗ hình sông lác/tuận lự 68 4.4.2 Quân lý kho

4.4.5 Xây đựng các tỉnh huông kiểm thứ 7

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

2| Hình 2: Chuẩn đặc tá miễn 18 3_ | Hình 3: Các tink hung phat sinh i trong quá trình phát triển +

phần mềm

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

6 | Hình 6: Quy trình kiểm thừ cẫu phần trang hệ thống 38

7 | Tlinh 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 usc casc quản lý giau dịch ATM 40

5 | 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 | IIình 11: Các khái nệm liên quan đến hành vi kiếm thử 40

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

14 | Hình 15: Mô hình tuân tự mô tâ giao địch A'TM 60

16 | [linh 17: M6 hinh cau phan phuc vu giao dich giti/rat tiên ATM 63

18 | Hình 19: Vĩ dụ xây đựng trên nên javabean 64

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

Bang 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,

UML hỗ trợ các loại kiểm thử 35

THUAT NGU SU DUNG TRONG TAI LIEU

ngữ

CBSE Component-base software Công nghệ phần mêm trên cơ

RM-ODP | Reference Model of Open Mô hình tham chiêu của quy

Distributed Processing trình phân tán mở

Interfaces

ADT Abstract data type Kiéu dữ liệu trừu tượ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 cau phan

RTE Real-time and embedded system | Hé thong nhung va thời gian

thực TDL Interface Definition Language Ngôn ngữ định nghĩa giao diện

€nvironment

CIG Component Interaction graph Lược đô tương tác cau phan

architechture

DF Developing for reuse Cau phan phat trién đê sử dụng

lai

Trude hét tôi xin gửi lời cảm ơn đặc biệt nhất tói PGS.TS Dặng Văn Dức viện

Công nghệ thông tỉa 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 Trưng tâm Dac tao Sau đại học và các thay

cô giáo trong Khoa Công nghệ thông tin, Trường Đại học Quốc Gia Hả Nội đã tin tinh

giảng đạ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ả oác bạn bẻ, các thầy oô giáo, cáo động nghiệp Khoa Công nghệ thông lin, 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 lôi xin đà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 (ôi, động viên, cla sẽ cùng tôi trong suối thời gian học cao học cũng như

quá trình thực hiện lun vin cao how

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

Văn Thị Hồng Phúc

LOI CAM DOAN

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 ƯMI” 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

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

Học viên

Văn Thị Hồng Phúc

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 trinh kiểm thử được xây dựng nhằm đạt các mục tiêu chính như sau:

dung lại lâm tăng chất lượng phần mềm Thco Daul Allen thì hiện nay có đến

trong phát triển phần mềm Trong đó, tính đóng gói, trừu tượng hóa và

hon 70% hệ thông phần mềm mới dượ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é phan tin 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 đựng, chúng ta sir dung ngôn ngữ mô hình hỏa chudn UML

Ngén ngit mé hinh hoa thong nhat (UML — Unified Modeling Language)

được công nhận là chuẩn sông nghiệp cho việc phân Lich và thiết kế các hộ

thống hưởng đối tượng UMII, cung cấp các ký pháp biểu dỗ thể hiển các thông tin thiết kế du6i các góc độ nhìn hệ thống, 'Irong những năm gẦn đây, đã có nhiều nghiên cửu sử dụng mô hình MT như ngudn thông tin dầu vào cho kiểm

thứ phần mềm Thí dụ biểu dé trang thái UMIL được sử dụng biểu diễn hanh 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 điễ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 phan mém theo cấu phần đã làm

giảm chỉ phi oủ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 co sở cầu phần quan tâm đến cách xây đựng phần mềm nhiều hơn Thông qua việc sử dụng lại các cấu phan, vong doi phat triển phần mềm dược rút ngắn lại, dồng thời tăng tỉnh mềm đế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 nay 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 Ereed 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 tap, Brooks viét mét chương với tiêu đề là

“No Silver Bullet” gidi thích rằng các hệ thống phần mêm là phức lạp Ông dự

hoảng nảy sẽ cỏn tiếp tục cho dén khi một kỹ thuật mới như công nghệ phần

mễm trên co sé cau phan (CBSE — Component based software engineering) trở

niên có tính khoa học vả nó thực sự đựa trên tính khoa học

Và như thể, CBSE đã dư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 trinh 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

Buïld” và “Rcuso bcforc Buy” Các khái niệm mắu chốt được đưa ra nhằm giúp

piảm được chỉ 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 dã 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ẩm

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 mmả hậu quả việc hỏng hóc phần mêm tăng theo mọi mức độ nghiêm trọng” Dễ 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 đựa trên việc

thiết kế các modulc thành phần hay oáo 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 dượ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 va dat 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ận trình Œ (Nội dung được đúc kết rong cudn sach Object-

Oriented Programming — An Evolution Approach 1986)

IBMI 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 dung trong phần mềm cầu

phần đó là OI.E 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 UMIL vào kiểm thử phần mém trén cơ sở cấu phần Từ đó, áp dung 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 dụng nghiên cứu tập trung vào mỘi số vẫn đề sau:

1) Tổng quan về các vấn dễ 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 pom các khái niêm cơ bắn như cấu phần, chuẩn Lương lác, chuẩn kết hợp, cải đặL

mô hình cầu phần, các mô bình cau phan - dịch vụ cdu phan, tiép cin 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 phan, 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

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

Lập trình hướng cầu phần (COP — CŒomponent oriented programming) va công nghệ phần mềm trên cơ sử cấu phần (CB8E — Component bascd softwarc engineering) đôi khi có thể hiểu là một Tuy nhiên, CBBE là thuật ngữ rộng hon,

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

CBSE = COA + COD + COP + COM

Trong d6 COA (component oriented analysis), COD (Component oriented

design) va COM (Component oriented management) thé hién cae thuat ngit 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 ŒPBSE 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à đuy 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 tap, 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 đế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 CDSE 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 sông nghệ phần mềm truyền thông, quy trinh phát triển phần báo

gồm các hoạt động hoặc các trạng thải tuần tự, cách dặ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 hước thực hiện như quy trình phát triển truyền

thống, va 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

thay ring, đ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, số 2 loại hoạt đông cần bản đó là: Phát triển

cấu phần để sử dụng lại (DE ~ Devcloping for reusc) và sử dụng lại các cầu phần

đã có sẵn (DW - Developmg with reusc) Với việc phát triển cầu phả để sử dụng lại có thể dượ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

điện: (1) giao điện cung ứng định nghĩa các dịch vụ quảng bá cấu phần này sẽ cung ứng va (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

trong CBSE

1 Đặc tả cấu phin (Component specification): Nó thể hiện don 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 dược định nghĩa dưới dạng tập các giao điện Một đặc tả

cấu phần được nhận diện đưới dạng môi thie thi cấu phần

2 Gian diện câu phần (Component iaterface): Giao điệ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 £4 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 dặt vả thay thế một cách dộ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 dat (Installed component): La sự sao chép của

một thực thi cấu phần đướ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 phan

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

5 Đối Lượng cầu phần (Compenent ohjcel): Một đổi tượng cấu phần là một

thể hiện của cấu phần được cải dặt Khái niệm này khá ping 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

Dé tim 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 CDST, ta đi từ các

khái niệm nhó nhất, đơn giản nhất về cau phan

Một phẩn tử phần mm 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 địch các câu lệnh

sang dạng máy thực thi được

6

M& ngudn phan mềm là tập các fle may od thé doc đượ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 trinh Các câu lễnh nay duoc

dịch thành các câu lệnh thực thí dược hoặc nhở vào bộ biên dịch hoặc hộ 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

Gấ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 TZET 610.12 — 1990) Thuật ngữ phần tử được đặt trong phạm vì 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 phan 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 lập hợp các phần tử phần mềm xác

định cần có dễ hỗ trợ việc thực thị của các cấu phần Luân theo mỗ hình

©- Hạ tầng của cầu phần phần mềm, là một tập hop 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

phan phan mềm, gáo 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à cach ding 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ó dị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

xà 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

†ả giao điện và tương tác sẽ cho chúng ta biết được nó làm gì (whaÐ, nội dung của mã thực thi trong câu phần, quy trình xử iÿ (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

tất cả gác thao tac được định nghĩa bởi giáo điện Một cấu phần cần một giao

dié

diện này

êu câu, nêu cầu phần dó dòi hồi một tương tác dược dịnh nghĩa trong giao

à 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 Miộ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 điện được định nghña rõ rằng và được tải liệu hỏa Một chuẩn tương lac

định nghĩa các phần tử của một giao điệ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 dược đặc tả tưởng minh trong tải liệu cầu phần, Chuẩn

tương tác bao gdm các tương tắc trực tiếp và gián tiến ĐIữ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 lườ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 chudn twong tac

đặc tả dạng các phụ thuộc bối cảnh tường minh ma cấu phan 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 Lí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 điện lập trình ứng dung (APIs - Application Programming

Tntcr [accs) 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 dịnh nghĩa rõ ràng phụ thuộc bếi cảnh

tường minh này

HE cd thé sit dung lai va kết nối giữa các cầu phần, nha 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 qua

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

tả Phần

giao diện chỉ mô tả tên của các phương thức, kiểu sủa các tham số, và giá trị trả

vào thông tin mà chúng ta muốn chửa đựng, và mức chỉ tiết của đặ

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 dơ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 TIBI va cdc cau

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]

8

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 dặt cầu phần

2) Cấu hình câu phan va HDH, néu cần

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

Aáã nguôn của cẩu phần phân mềm là tất cả các file mà maáy có thể đọc được

(các thủ tục và mỗ-đun) vả máy có thể thực thị (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 nhim:

e _ 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 chỉ phí cải đặt và triển khai

e© _ 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 dé

Một chuẩn kết hợp định nghĩa cách thức soạn cấu phan dé tao 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 phan 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ử đụng

phát triển cầu phần đó và đã

đủ đặc Lá Nhà sản xuất cấu phần hoặc tổ chức chứng nhận thứ ba sẽ quyết dịnh

dạng thích hợp nhất cho tải Hệu, đó là lưu trữ nó cùng với cầu phân theo cả hai

đạng mã nguồn hoặc nhị phân, hay cung cấp dộc lập Điểm mạnh cửa phần mềm

bảo rằng sẵn phẩm cuối cùng đáp ứng được đây

«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 đủ 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 phin(CBSE component base softwar engineering) duge 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 vii CBSE

Vấn đề trước hết là các Lễ chức phát triển phần mềm và các phòng địch vụ thông

tin thường có ghanh dua về vấn dé quy tinh dã đượ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 ban 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ử đự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 va Frost 1998) được đưa

Ta bởi khách hàng hoặc doanh nghiệp (Lles 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ế dạ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 dầ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 chỉ

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 Dễ 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 điện yêu cầu, các dich 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

à thuật ngữ

thường được sử dựng trong quá trình thiết kế là lấp dây khoảng trồng Quả trình lắp khoảng trắng có thể dưa đến một trong hai kết luận sau

i) Cấu phần piếng như yêu cầu đã dược tỉm thấy và dưa vào sử dựng,

1i)Không có câu phân nao như thể tồn tại

Dié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 đự án con để xây dụng một cầu phan theo dic

†ả Diễu này có nghĩa là quy trình lưu trữ không chỉ nắn giữ các các cầu phần đã

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 hang

đư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

u phần, diều này đạt được thông qua việc lập kế hoạch và thiết kế

đó Bởi vì các phiên bản mới của một cấu phần có thể được cung ứng hất cứ lúc

nao, 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áo cầu phần cập nhật, lưu trữ Người

xây dựng giải pháp co thé dé dang 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 dạt được nếu người xây dựng giải pháp có xác nhận ding 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

vong doi 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 Miộ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 San xuất cầu phần thì khác, người ta mắt nhiều thời gian hon dé

nghiên cửu về các quy Lắc nghiệp vu, mô hinh quy trình nghiện vụ, phân lich va

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 Để Lìm hiểu một cách chỉ tiết vỀ vòng đời cầu phân ta di dến dị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 trinh nghiệp vụ, thiết kế, xây dựng, duy tri kiểm thứ, triển khai, mở rộng,

duy trì sử đụng lại va bao ti

Các giai đoạn phần tích và thiết kế cho 1 CSLC là đặc biệt đải hơn so với

vòng đời phát triển nhằn mềm truyền thống Iloạ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ử dơn vị ta sử dung 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 dội tham pia 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 phan

của họ tương tác với cáo chức năng và hành vi của hệ thống gọi cầu phần trong

C8LC

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

thống với vòng đời phat tnén CBSE

Băng I So sánh vòng đừi phát triển trên cơ sử cấu phần với vòng dời nhá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 'Vòng đời phát triển CBSE

truyền thống

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

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

4 |Tara chọn mỗi trường phát triển Lựa chon môi tường phát triển tương

tương tác (IDH - Interactive cnaronmment) development

development environment)

5 | Xay dựng cơ sở đữ liệu Xây dựng cơ sở đữ 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

2.3 Cae mô hình cầu phần và dịch vụ cắu phân

Cấu phần ở mức ứng đụ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ó 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 lcỳ ứng dụng nảo cũng

có thé cd CBSE tim ra các nhân tổ chung đưa vào các các dich 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 cau phần Tư tưởng trọng tâm của CBSE là phát triển các công nghệ chỉ 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

ửng dụng, nhưng các giao diện ứng dụng thường đặc tả kém va 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 vi kết hợp,

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

đị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 địch vụ khác nhau và giao

điện lập trình ứng dung (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 ƠĐSE 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 dich vu Sw tham gia cla CBSE 1a dé dinh 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 hop dé kich hoạt các cấu phần va 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]

Mic tic nhat: Mot mé hinh cau phan định nghĩa cách xây dựng Lừng cầu

phần riêng lẻ

Mức thứ hai: Miệ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 phan tạo nên sự kết hợp bằng việc định nghĩa một chuẩn tương tác

va nang lên thành giao diện đặc tả tường minh Miộ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 há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ị dượ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 dủ phức tạp dễ thu dược kết quả đặc tả chỉnh xác Chúng †a sử đụ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 dang cải tiến của tương tác Một mé hinh 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 dang mi, cic 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 gdm: cai dal cầu

phan, đắ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 dị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 dố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ô hinh thành

JavaBeans cta Microsoft Khéng nhat 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 Weimreich và Sametinger liệt kê chỉ tiết - 2001 Ilình đuới đây tổng hợp lại các phần tử trong

mô hình cầu phần, nó chi ra ring các phần lử đã được phân loại thco các giao diện cầu phần, các phẫn tử liên quan dến thông tin ma han can sứ dụng dén cầu phan đỏ trong một chương trinh và các phần tử tập trung vảo việc triển khai cầu

phan

Kết cầu siêu dữ liệu

| đạiên | Sự i biến Đếnggổi | 8 ty phattién

Giao diện |Thöng tin cung cắp Triển khai và sử địng —

Miột phần quan trong của mô hình cầu phân là định nghĩa cách mả các cầu

phần nên được đóng gói triển khai độc lập để các đối tượng thực hiện được Bởi

vỉ các cầu phần là những thực thể độc lập, chúng phải được đóng gói mệt cách

độc lập với hạ lãng cấu phần xác định hoặc không được định nghĩa trong một

giao điện yêu cầu

2.3.1.1 Các phần tử của một mö hinh 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 đữ liệu giữa các cấu phần

kháo nhau oủa các nhả sản xuất cá a

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: piao diễn, đặt tên, siêu đữ 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 dung 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 Lhức lừ xa, và chuẩn báo mật Các ứng dựng nghiệp vụ

3 lớp cần các địch vụ giao địch được chuẩn hoá và cơ sở đữ liệu APIs Cudi

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 Lá từng

phan, cde quan hệ bao hàm và giao diện C4c m6 hình edu 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à

Mục đích của các cấu phần là được sử đụng lại trong phần mễm IIai 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

n ngữ định nghĩa giao diện

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 dây di

và có thể nghiên cứu, sử dụng lại, lấp phé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 dối tượng, dap img site

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 den dựa trên nguyên tắc che giấu thông tin Người đừng cầu phần chỉ có thể đựa trên vào các giao điện Các giao điện này là sự mô tả hoặc

đặc tả hành vi cầu phần Thông qua các giao điện, các lời gọi cấu phần có thể

ằu định nghĩa Giao điện thể hiện một cách

tuémg minh va qua các oông cụ chẳng hạn như bộ biên dịch, có thể kiểm chứng

được thay dỗi tiếp tục thỏa mẫn y

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ụ ching 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 điệ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 clent của nó Các đặc tã giao điện là phan

tử trung tâm trong một mô hình cầu phần Miệt mô hình cấu phần định nghĩa

cách mà một hành vị 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 lả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 pằ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 r: lo điều kiện trước, điều kiện sau

phải được dán ứng khi sử dụng các thao tác né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 dặt cầu phần Nhiều mô hình cấu

phần có một ngôn ngữ định nghĩa giao điện (TDI, — Interfaoc definition

16

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

Mô hình cầu phần có thể dịnh nghĩa một tập các giao diện đặc tả cần dượ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 đã dược chứng nhận, như các kết nối Internet băng thông rộng, sẽ làm thay dễ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 di 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 đựng ứng dụng Các kết nỗi internet nhanh hỗ trợ người

ding 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 dó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 dit va 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 cu thé và cung cắp một giao diện thì bên gọi có thể sử đụ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ề oú 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ả gian diện - IDEs cho việc mô tá các

lao diện II21.s dược dịnh nghĩa bởi OORBA, COM và COMI— 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 HIDH nhưng nó sẽ chỉ khiến HDH trở nên

phúc tạp thêm, vả hạn chế tỉnh ứng đụng của mmô 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 IIĐIL Các IIĐII đã

nhiệm có thé di chuyển lớp này dé đả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 dịnh cách một giao điệ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 điê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

cụng 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 ấu phan Như vậy, sự cải đặt mô hình cầu phân giúp khả năng thực thi

Â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 sấu phần, mô hình cầu phần dó có thể bị trở thành độc quyền

các

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 Diéu này bao gồm đặc tả giao diện cho cả hai dich 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-persislence support)

và bản quyền Mô hình cấu phần trong hệ théng phan lin 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 lừ xa

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

M6 hình cấu phần hỗ trợ việc xây dựng các hệ thống thông tin da lớp đặc tả giao

diện lập trinh ứng dụng (APls) truy cập đữ liên và các đị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 ly déi trong (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 đụng trên cơ sở dối tượng phân tản

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

Các mô hình cấu phần nỗi tiếng khác nha COM cilia Microsoft va JavaBean cia

Sun định nghĩa các dịch vụ giống nhau có ích trong các hệ thống đa miễn lắt cá

Hiện nay, một số HDH 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 én CBSE

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ự tuy 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 địch vụ ngang có tác đụ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 phat trién phan mém

Ngén ngit M6 hinh théng nhat (UML-Unified modeling language) là chuẩn

ngôn ngữ với mê hình chủ thể thế giới thứ ha Iiện nay UAMI 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 la ứng dụng UMU,

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ự dơn giản hoá hiện thực Mô hình dược xây

dung để chúng ta dễ dàng hiểu và hiểu tốt hơn hệ thông cần xây dung [6]

Tỏ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 chỉ tiết không quan trọng, khiến cho bài toán trở nên đễ hiểu vả dễ nắm bắt hơn

tiệc biểu diễn mô hình thoâ mẩn cdc yéu td sau:

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

© Đông nhất (consistent): Cae viow khác nhau không được mâu thuẫn

với nhau

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

dụng

® 108 thay dai (changeable)

© Dé dang 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 dang dượ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éhinh hoa các hệ thống, sử đụng các khái niệm hưởng đổi tượng

Củng với việc sử dụng ƯMT người dùng tạo ra mô hình ứng dụng Mục Liêu

của nó là tạo ra một mô hình hoàn chỉnh, én dịnh và chính xác Nếu được thực

20

hiện dimg din, 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 dễ 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 wu điểm như giảm nguồn lực và bảo tri

tính ỗn định giữa mô hình UMI, 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 lỗ chuẩn áp dụng cho việc mô hình hod phan mém CO rất nhiều cơ sở đã khẳng định điều này:

© "Trước hết, UMI có một mô hình ngữ nghĩa nên tảng được đinh

nghĩa rð rảng, gọi là siêu mô hình ỨMIL 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

hệ thống mà ta cẦn va thể hiện

© ‘Thur hai, UML ding các ký hiệu rất chuyên nghiệp và dễ hiểu Mặc dù

một số người cho rằng UML có quá nhiều đường biểu đồ, nhưng thực tế chỉ

có một số được sử đụng thường xuyên như biếu đề cầu trúc đép) tiểu đề triển khai, biểu đề trạng thái, biểu đồ hoạt động, biển đỗ các ca sử dụng và

các biểu đồ tuần tự Chúng hoạt động theo phương thức rõ rằng và theo một

số nguyễn tắc chưng

thé lựa chọn công cụ và dịch vụ từ rat nhiều nguồn khác nhau

»_ Cuối cùng, MT, có khả năng ửng dụng, Trở thành ngôn ngữ mô hình

hoá hướng đối tượng thế giới thứ ba, chúng ta có kinh nghiệm hàng thập kỹ

qua trong việc áp dụng các các phương thức hướng đối tượng vào hệ thông phát triển, bao gồm cả các hệ thống nhúng và hệ thống thời gian thực

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

TẤ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 UMIL 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

2A.2 Vai trò, vị trí của các lược dé UML trong vòng đời phần mềm

UML o6 thé durge sit dung trong nhiéu giải đ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 địch, phần mềm hệ thông

DM, có mặt trong hẳu hết các giai doạ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

mmiều tả se 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 vì bài toán Ciass điagrams 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 (cfass) nằm trong phạm vi bài toán mới đáng

quan lãm

Thiết kế: Kết quả phan analysis duoc phát triển thành giải pháp kỹ thuật Qác lớp dược mô hình hóa chỉ tiết để cung cấp hạ tẦng kỹ thuật như giao diện, nền tảng cho database, Két qua phần Design la các đặc tả chỉ tiết cho giải

© Kiém thi don vi (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 hyp (integration diagrams & callaboration 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 dễ xem

chúng hoạt động với nhau só dũng không

©_ Kiểm thử hệ thống (use-case diagrams) kiém tra xem hé théng có đáp

mg được chức năng mà người đủ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 dượ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é thing

2.4.3 Các công cụ xây dung 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ử đụng một vải quy chế kiểm tra tính nhất quán hoặc một vai 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ể đà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ụ đã dược sử dụng,

để nhằm mục đích hỗ trợ xây dựng UMI như Ratianal Rose, GI3ro, 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 Thữ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à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 mình để hiểu muc dich cha

các biểu đỗ vả biết được những ngữ nghĩa cũng như các quy tắc don giản, đủ dé

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

Hnat độ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

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

đình hướng và chuyển dịch trong mô hình để theo dõi một phần tử từ biểu đồ

nay sang biểu dầ 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ụ ỗ trợ cho nhiễu người dùng, và tao

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

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

thành phan 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 lại, hoặc một nhà phát triển có

thể đễ dang 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 ông cụ cần phải có khả năng lich 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

ban

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ân 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 đỗ

Tran déi mã hình: Một mô hình hay một biểu dỀ của một mô hình nào dé 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 4p dụng cho các mô hình trong một ngôn ngữ mô hinh hóa được định nghĩa

chính xác

hư 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à để kiểm thử hơn cái phần mềm mà nó biểu

diễn? Trong cả hai tình hudng, cau tri loi không bao giờ rõ rảng Không có

phương pháp chắc phấn nào để kiểm tra các luge 46 UML Ching ta v6 thé nhìn

chúng, định lượng chúng, áp dụng các nguyên lắ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 dánh giá chúng vẫn rất chủ quan Vẽ lược dd

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 đễ hơn rất rất nhiều lần so với việc thay đổi một lược đổ Tại sao

†a nên sử dụng các công cụ UML? hay dùng công cụ xây dựng UMIL có phải 1a cách hợp lý không? Ta sẽ không sử đụng một mô hình UMIL nếu như đùng nó lả

khéng hop lý Tuy nhiên, những lập luận trên nhằm giải thích rằng UML rất đễ

bị dùng sai mục đích Chúng ta sử dụng UML khi chúng ta có mệt thứ gi đó má

chúng ta dứt khaát phải kiểm thử nó, và khi dimg UML dé kiém thử thì rễ hơn là

dùng mã nguồn dễ kiểm thử nó Vỉ dụ, nói rằng tôi có một ý tưởng chủ một thiếU

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 dấy lá một ÿ tưởng dúng đắn không, Vì vậy tôi vẽ lược để UMI, lên bang và hồi thành viên trong nhóm để nhận phan héi

Sau khi các thành viên đã thông qua ý tưởng trình bảy (lược đỗ UML), dộ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

24

2.5 Ly 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 :

mm, 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 di vào

cuộp sông của chúng ta Ta sit dung phần mềm vào oá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 hoa den voi giao dich mua ban, 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 dé có chung một dang ả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 dé chứng La gặp phải là Lá sử dụng phần mềm rất thường xuyên nhưng có thể chỉ 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 đễ đảng và chắc chắn rằng chỉ gia

đình tôi biết được điều đó

TNếu như trang web công ty có một số lỗi chính tâ, khách hàng co 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

2.5.2 Nguyén nhan gay Idi phan 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 đó Niếu lỗi phát sinh từ trong code

đẫ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 la có thể là nghiêm trọng bởi vì sáo 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 la 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é dé

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

ho 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 oáo 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 la 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 dề 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í đụ như một vụ nổ bức xạ, từ trường mạnh,

các lĩnh vuc 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 vị 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ỏi có thể cững xuất hiện đo sai

lim của người tương tác hệ thống phần mềm, có thể là giả trị dầu vảo sai hoặc

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

Khi ta nghĩ dến những gì có thể làm sai hướng ta phải nghĩ dế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 hdc bén trong

hãy được số náo 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 phan mém

`Y&u câu 1 'Yêu cẫu 2 'Yêu cầu 3 'Yêu câu 4

Đắc à âu cầu Pict yêu rằ đăng Tấn tà vê cầu đúng Libro aie tt yu edu

TH tan ra Thất gap ura doe Zˆ Gas Tritt kd eg thon xây

/ Xây dụng hong tinh sy 4

Xây đưng đL1: 19 dung

Sản phẩm comes „ý

năng và phi chức trình căn được sửa gỗm cả kiểm thử viên năng bản giao ding

theo mong dl

kế đúng đáp ứng đầy đủ yêu cầu, xây đự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 lhiện, đễ

iêu cha người dùng

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

ta gây ra một số sai sỏi, 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 la có thể thấy sản phẩm trước

khi tiến hành kiểm thử sẽ không dap img dặ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ế

gay 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 la

thấy sẵn phẩm dã đá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 dỏ có thể bị loại bởi khách hàng hoặc người đù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 chỉ 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 Chỉ phí sửa lỗi là gi?

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,

†a cần phải xem xét các ảnh hưởng khi tìm ra các lỗi này Chỉ 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 để làm, nhưng nếu bạn để lại đó, nỏ sẽ hông Lệ hơn và cần nhiều mũi vá hơn mới sửa

được

ếu ta liên hệ lại theo một chuỗi các cái đã đề cập từ trước đến hình đưới dây, ta thấy rằng, nếu một sai sót gây ra và kết quá là lỗi dược tim thấy tại giai

đoạn đó thì liên quan đến việc ch phí tìm và sửa lỗi là rẻ Ta thấy sự tăng chỉ

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 Dặ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ế chỉ phí để sứa chữa sai lầm là íL hơn

nếu nó được phát hiện ở các giai doạn sau

'Yêu cầu Thiết kế Xây dựng Kiểm thử Bảo trì

'Tuy nhiên một lỗi xuất hiện trong đặc tả yêu cầu mà không được phát hiện

cho tới tân khi tiến hành kiểm thử chấp nhân hoặc thậm chí cho tới khi cải đất hệ

thống, thì chí phí sửa nó sẽ đắt hơn rất nhiều Điều này là bởi vì để sửa được lỗi

đó, 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 ở bat ky 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

nhập đữ liệu đầu vào hoặc đưa ra kết quả dữ liệu dau ra, va tim 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ứ piúp chúng ta cải thiện dần chất lượng sản phẩm và dich vu, đó 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

lệ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 dượ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

†a 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 thi, Chang ta cin 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 đó

Thư 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à da? Ví du, có bao nhiêu trường hợp sẽ cân phải Liễ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á Irị số đúng,

gid tri sai sẽ bị loại bố đó 26 ký tự viết hoa, 26 ký tự viết thường, it 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ó # nhất ó8 trường hợp

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

‘Thue 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í

đụ một màn hình nhập có 1Š 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

$15 trường hợp! Điều đỏ có vé không hợp lý để thực hiện được số lượng cả

kiểm thử là quá lớn

Áp lực trên một du an bso 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 dược mong muốn của khách hàng Khách hàng,

và gá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

30

chặn được các hồng hóo sau khi bản giao, góp phần vào chỉ nhí sản phẩm Công

việc kiểm Ira là hoàn thành - nếu nó dơ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 ra về phía khách hàng, sfackhalders, dự án và phần mêm

Tánh giá và quản lý rủi rơ là một trong những hoạt động quan trọng của bat ky

đự á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ề lzÿ thuật và nghiệp

vụ liên quan đến sản phẩm và ràng buộc đự án như thời gian và ngân sách

Kiểm thử cung c&p thong tin tin cay cho cdc stakeholders, dé thong bao các

quyết định bản giao phần mềm hoặc hệ thống ma ta kiém tht, chuyén đến bước phát triển tiếp theo hoặc bản giao cho khách hang Kgué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 dến các rủi ro và các chỉ phí được kết hợp véi du én Do sw han 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ử đưới dang quy trình, sau đó là các đối

tượng của quy trình kiểm thử

-_ Quy hì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

- Tal cd các hoại động theo chư trình - Lỗi được phát biện càng muộn trong vòng đời tìm lỗi thi chỉ phí sửa lỗi cảng cao Nếu ta có thể tìm và sửa

ỗi ngay ở giải đ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 mm dược nâng cao Chúng ta sẽ xây dựng dượ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ừ dầu có thể ngăn chặn được các lỗi sinh ra ở giai đoạn code về sau Đôi khi

†a 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

- Ca kiém thứ ứmh và động - Các ca kiểm thử bằng việc thực thi code để

chứng mỉnh 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 Lá cũng có thể từm ra các sai sót mà không chay đoạn cođc nào -

cách kiểm thử này pọi là kiểm thự tĩnh Việc kiểm thứ tĩnh bao gồm xem xét

lai liệu (gồm cá mã nguồn) và phân tích lĩnh Đây lá lợi ch và hiệu quả chỉ

phí của kiểm thử

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

thử Chúng la 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; diều khiển các hoạt dộng kiểm thử, báo cáo tiển

trình kiểm thử va trang 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

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ử

-_ Dáả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 đưới góc độ kiểm thử và điều kiện

toàn thành giúp ta quyết định xem cé kél thúc công việc kiểm thử hay không

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

-_ Đỏ lỗi — Chúng ta thường nghĩ về kiểm thứ phần mềm với ý nghĩa là

dé tim 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ử đụ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ỏ dem lại cho chúng La 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 La có thể sử dụng cã bai 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 dượ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:

hoạt động xem xét — tìm và sửa lỗi cần được thực hiện sớm và kịp thời ngay khi

chúng còn ở mức chỉ phí thấp Mỗi lần codo được viết ra, lập trình viên, nhân

viên kiểm thử thường chạy một tập các tỉnh huồng để có thể xác định lỗi và sửa lỗi phần mềm

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

32

bông hóc, sáo 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ư mona đợi, dáp tứng dược dầ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 Dôi

khi, ta chỉ muỗn tập hợp thông tin và đo được chất lượng phần mềm ©?ó 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 ban giao sản phẩm

2.5.3.4 Cac yéu té co ban trong kiém thee [2]

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

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

sủa lỗi 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 dung

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ả

sẽ lập trưng nguồn lực vào việc xem xét

các rủi ro, và mức độ ưu tiên

Các hoạt động kiểm thử hệ thống hoặc

3 | Kiểm thử sớm vong doi phat 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

Một số các module chứa hầu hết các lỗi

4_ | Phân vàng lỗi phát hiện được trong khí tiến hank kiểm

thử, hoặc chỉ ra các lỗi thường xuyên

nhất

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ẽ

5 | Loại trừ các lỗi lặp không tập trung tìm được các lỗi mdi Dé

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ến

thử mới phải được viết ra và thực hành

với các phần khác nhau lrong phần mom

hoặc hệ thống để tìm các lỗi tiềm năng

Kiểm thủ phụ thuộc ngữ

cảnh

Thiếu các lỗi giả đị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

thong mai

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 pỉ người dùng cần

và mong đợi