ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
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
MỤC LỤC
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
DANH MỤC HÌNH
#
Tên danh mục hình
Trang
Hình 1: Các phần tử cơ bản của một mô hình cấu phần
14
18
4
Hình 2: Chuẩn đặc tả miền
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
Hình 4: Chi phí sửa lỗi qua các giai đoạn phát triển
5
Hình 5: Cấu trúc một cầu phần
34
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
1
2
3
26
28
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
ATM
14 Hình 15: Mô hình tuần tự mô tả giao dịch ATM
59
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
17 Hình 18: Cây cấu phần JtextComponent
64
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
60
DANH MỤC BẢNG
#
Tên danh mục bảng
Bảng 2
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.
Các yếu tố cơ bản trong kiểm thử
Bảng 3
UML hỗ trợ các loại kiểm thử
Bảng 1
Trang
11
32
35
THUẬT NGỮ SỬ DỤNG TRONG TÀI LIỆU
Thuật
ngữ
QTDA
CNPM
CBSE
Từ gốc
ADT
UML
Project manager
Software engineering
Component-base software
engineering
Reference Model of Open
Distributed Processing
Application Programming
Interfaces
Abstract data type
Unified Modeling Language
OMG
COM
CSLC
RTE
Object Management Group
Component Object Model
Component Software Life Cycle
Real-time and embedded system
IDL
HTTP
XML
IDE
SUT
DF
Interface Definition Language
HyperText Transfer Protocol
eXtensible Markup Language
Interactive development
environment
Quality of Service
Operating system
Component Interaction graph
Commercial components
Object management
architechture.
System under test
Developing for reuse
DW
Developing with reuse
RM-ODP
APIs
QoS
HĐH
CIG
COTs
OMA
Giải thích
Quản trị dự án
Công nghệ phần mềm
Công nghệ phần mềm trên cơ
sở cấu phần
Mô hình tham chiếu của quy
trình phân tán mở
Giao diện lập trình ứng dụng
Kiểu dữ liệu trừu tượng
Ngôn ngữ mô hình hoá thống
nhất
Nhóm quản lý đối tượng
Mô hình đối tượng cấu phần
Vòng đời phần mềm cấu phần
Hệ thống nhúng và thời gian
thực
Ngôn ngữ định nghĩa giao diện
Giao thức truyền siêu văn bản
Ngôn ngữ đánh dấu mở rộng
Môi trường phát triển tương tác
Chất lượng dịch vụ
Hệ điều hành
Lược đồ tương tác cấu phần
Các cấu phần thương mại
Nhóm quản lý đối tượng
Kiểm thử hệ thống
Cấu phần phát triển để sử dụng
lại
Cấu phần sử dụng lại
LỜI CẢM ƠN
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
1
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à
2
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
3
dựa trên ngôn ngữ lập trình C (Nội dung được đúc kết trong cuốn sách ObjectOriented Programming – An Evolution Approach 1986)
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ử.
4
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.
5
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.
6
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ì.
7
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].
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 đặ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
9
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 đã
10
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
11
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
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ụ
2
Quản lý yêu cầu
Quản lý yêu cầu
3
Mô hình thiết kế hệ thống
Mô hình thiết kế hệ thống (cấu phần)
CBSE
Lấp đầy khoảng trống (gap fullfilled)
CBSE
Đặc tả cấu phần mới
CBSE
Đưa cấu phần vào sử dụng
CBSE
Lập danh sách thư tín (liên hệ)
4
Lựa chọn môi trường phát triển Lựa chọn môi tường phát triển tương
tác (IDE - Interactive development
tương tác (IDE - Interactive
environment)
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
8
Kiểm thử
Kiểm thử
9
Đóng gói
Đóng gói
CBSE
Tiếp nhận cảnh báo, cấu phần mới
CBSE
Xem xét cấu phần mới
CBSE
Cập nhật thiết kế
10
Bảo trì
Bảo trì
11
Mở rộng
Mở rộng
12
Kết hợp các hệ thống
Kết hợp các hệ thống
12
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]
13
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.
- Xem thêm -