Tìm hiểu qui trình xây dựng phần mềm và ứng dụng vào phân tích quản lí khách sạn

PHẦN 1. MỞ ĐẦU
1.1. Lý do chọn đề tài
Công nghệ thông tin là một ngành công nghệ mũi nhọn, phát triển bùng nổ và
em chọn khi qua Việt Nam học. Rất nhiều kiến thức hay và bổ ích được thầy cô
truyền đạt trong suốt bốn năm qua, tuy nhiên do ngôn ngữ tiếng Việt còn hạn chế do
vậy không đọc được nhiều tài liệu và không nắm được hết kiến thức chuyên ngành.
Để bổ sung kiến thức chuyên ngành còn chưa vững, học tập cách xây dựng phần
mềm phục vụ cho công việc tương lai ở quê nhà em chọn đề tài “Tìm hiểu qui
trình xây dựng phần mềm và ứng dụng vào phân tích quản lí Khách sạn”.
1.2. Mục tiêu của đề tài
- Nắm vững các kiến thức về lý thuyết công nghệ phần mềm
- Tìm hiểu qui trình xây dựng phần mềm
- Triển khai phân tích ứng dụng quản lí Khách sạn
1.3. Đối tượng và phạm vi nghiên cứu
- Đối tượng nghiên cứu của đề tài là lý thuyết về công nghệ phần mềm, qui
trình xây dựng một phần mềm.
- Phạm vi nghiên cứu của đề tài được giới hạn trong các nội dung sau: về mặt
lý thuyết, đó là công nghệ phần mềm. Về thực tế, phân tích quản lí Khách sạn.
1.4. Phương pháp nghiên cứu
- Tìm kiếm tài liệu liên quan đến công nghệ phần mềm.
- Đọc tài liệu, chọn những công cụ cần thiết cho việc phân tích quản lí Khách
sạn.
- Phương pháp nghiên cứu lí thuyết.
- Sử dụng phương pháp thu thập thông tin phân tích và tổng hợp.
1.5. Lịch sử nghiên cứu
- Nội dung này được xây dựng thành học phần trong chương trình học. Tuy
nhiên, đây là nội dung khó với mong muốn bổ sung kiến thức của bản thân nên tôi
lựa chọn đề tài nàyđể thực hiện.
1.6. Đóng góp của đề tài
- Cung cấp kiến thức về công nghệ phần mềm.

1


- Cung cấp kiến thức về qui trình xây dựng phần mềm.
- Với đề tài này tôi mong muốn chia sẻ kiến thức và cung cấp một tài liệu
tham khảo cho các bạn sinh viên Lào đang họccông nghệ thông tin.
1.7 Cấu trúc đề tài
Với đề tài này, phần nội dung khóa luận gồm 3 chương sau:
Chương 1: Cơ sở lý thuyết
Chương 2: Qui trình xây dựng phần mềm
Chương 3:Phân tích quản lí Khách sạn

2


PHẦN 2. NỘI DUNG NGHIÊN CỨU
CHƯƠNG 1: CƠ SỞ LÝ THUYẾT
1.1. Khái niệm công nghệ phần mềm
1.1.1 Khái niệm

Phần mềm là chương trình máy tính và các tài liệu liên quan. Các sản phẩm
phần mềm có thể được thiết kế cho một khách hàng cụ thể nào đó hoặc cho thị
trường nói chung. Một phần mềm tốt là phần mềm cung cấp các chức năng, hiệu
năng yêu cầu cho người sử dụng. Nó có thể sử dụng được, đáng tin cậy và có thể
bảo trì.
Công nghệ phần mềm là ngành kỹ thuật liên quan đến tất cả các khía cạnh sản
xuất phần mềm.Các hoạt động nền tảng của công nghệ phần mềm là đặc tả phần
mềm, phát triển phần mềm, kiểm nghiệm phần mềm, và tiến hóa phần mềm.
Công nghệ phần mềm là sự thiết lập và sử dụng các nguyên tắc khoa học
nhằm mục đích tạo ra các phần mềm một cách kinh tế mà các phần mềm đó hoạt

động hiệu quả và tin cậy trên các máy tính
• Là các quy trình đúng kỷ luật và có định lượng được áp dụng cho sự phát
triển,thực thi và bảo trì các hệ thống thiên về phần mềm
• Tập trung vào quy trình,sự đo lường,sản phẩm, tính đúng thời gian và chất
lượng
1.1.2 Phân loại

Phần mềm hệ thống là những phần mềm đảm nhận công việc tích hợp và điều
khiển các thiết bị phần cứng đồng thời tạo ra môi trường thuận lợi để các phần mềm
khác và người sử dụng có thể thao tác trên đó như một khối thống nhất mà không
cần phải quan tâm đến những chi tiết kỹ thuật phức tạp bên dưới như cách thức trao
đổi dữ liệu giữa bộ nhớ chính và đĩa, cách hiển thị văn bản lên màn hình
Phần mềm ứng dụng là những phần mềm được dùng để thực hiện một công
việc xác định nào đó. Phần mềm ứng dụng có thể chỉ gồm một chương trình đơn
giản như chương trình xem ảnh, hoặc một nhóm các chương trình cùng tương tác
với nhau để thực hiện một công vịệc nào đó như chương trình xử lý bản tính,
chương trình xử lý văn bản,...

3


1.1.3

Kiến trúc phần mềm
Sau khi đã có các khái niêm cơ bản nhất về phần mềm, tiếp sau đây chúng ta

sẽ đi sâu vào tìm hiểu cấu trúc chi tiết các cấu trúc chi tiết các thành phần bên trong
phần mềm. Phần mềm bao gồm 3 thành phần:
a) Thành phần giao tiếp (giaodiện)

Cho phép tiếp nhận các yêu cầu về việc muốn thực hiện và cung cấp các dữ
liệu nguồn liên quan đến công việc đó hoặc từ các thiết bị thu thập dữ liệu (cân, đo
nhiệt độ, tế bào quang học, …)
Cho phép trình bày các kết quả của việc thực hiện các yêu cầu cho người dùng
(kết quả của công việc khi thực hiện trên máy tính) hoặc điều khiển họat động các
thiết bị điều khiển (đóng mở cửa, bật mở máy…)
Một cách tổng quát thành phần giao tiếp là hệ thống các hàm chuyên về việc
nhập/xuất dữ liệu (hàm nhập/xuất) cùng với hình thức trình bày và tổ chức lưu trữ
dữ liệu tương ứng, mục tiêu chính của các hàm này là đưa dữ liệu từ thế giới bên
ngoài phần mềm vào bên trong hoặc ngược lại.
Trong phạm vi giáo trình này chỉ giới hạn xét đến giao tiếp với người sử dụng
phần mềm và khi đó có tên gọi cụ thể hơn là thành phần giao diện.
b) Thành phần dữliệu

Cho phép lưu trữ lại (hàm ghi) các kết quả đã xử lý (việc mượn sách đã được
kiểm tra hợp lệ, bảng lương tháng đã được tính) trên bộ nhớ phụ với tổ chức lưu trữ
được xác định trước (tập tin có cấu trúc, tập tin nhị phân, cơ sở dữ liệu).
Cho phép truy xuất lại (hàm đọc) các dữ liệu đã lưu trữ phục vụ cho các hàm
xử lý tương ứng.
Một cách tổng quát thành phần dữ liệu là hệ thống các hàm chuyên về đọc ghi
dữ liệu (hàm đọc/ghi) cùng với mô hình tổ chức dữ liệu tương ứng.Mục tiêu chính
của các hàm này là chuyển đổi dữ liệu giữa bộ nhớ chính và bộ nhớ phụ.
c) Thành phần xửlý

Kiểm tra tính hợp lệ của các dữ liệu nguồn được cung cấp từ người dùng theo
các quy trình ràng buộc trong thế giới thực (chỉ cho mượn tối đa 3 quyển sách, mỗi
lớp học có tối đa 50 học sinh, …)

4

Tiến hành xử lý cho ra kết quả mong đợi theo quy định tính toán có sẵn trong
thế giới thực (quy tắc tính tiền phạt khi trả sách trễ, quy tắc tính tiền điện, quy tắc
trả góp khi mua nhà…) hoặc theo thuật giải tự đề xuất (xếp thời khóa biểu tự động,
nén ảnh…)
Chất lượng phần mềm

1.1.4

 Tính đúngđắn
Tính đúng đắn của phần mềm được thể hiện ở chổ sản phẩm đó thực hiện đầy
đủ và chính xác các yêu cầu của người dùng. Tính đúng đắn ở đây cần phải hiểu
theo nghĩa rộng làchương trình cần phải thực hiện được trong cả những trường hợp
mà dữ liệu đầu vào là không hợplệ.
Ví dụ, nếu một trong số các chức năng của phần mềm là sắp xếp một tập tin có
số lượng mẫu tin tùy ý theo một cột tùy ý theo chiều tăng hoặc giảm thì những
trường hợp sau là vi phạm tính đúng đắn của chươngtrình:.
- Không thể thực hiện được (treo máy) khi tập tin rỗng (không có mẫu

tinnào).
- Không thể thực hiện hoặc thực hiện nhưng cho kết quả sai khi các mẫu tin

có hơn 100 cột hoặc có quá nhiều mẫutin.
- Không thể thực hiện hoặc cho kết quả sai khi các cột có chiều dài lớn hơn

125 bytes.
- Không thể sắp xếp theo chiều tăngdần….Tính đúng đắn của một sản phẩm

phần mềm được xác minh qua các căn cứ sau đây:
- Tính đúng đắn của thuậttoán.

- Tính tương đương của chương trình với thuật toán. Thuật toán có thể đúng

nhưng chương trình lập ra không tương đương với thuật toán nên khi thực hiện sẽ
cho kết quả sai.
- Tính đúng đắn của chương trình có thể được chứng minh trực tiếp trong văn

bản của chươngtrình.
- Tính đúng đắn cũng có thể được khẳng định dần qua việc kiểm thử, việc áp

dụng chương trình trong một khoảng thời gian dài trên diện rộng và với tần suất sử
dụng cao.

5


 Tính tiếnhóa
Cho phép người dùng có thể khai báo các thay đổi về qui định với phần mềm
tùy theo các thay đổi trong thế giới thực liên quan (thay qui định về số sách mượn
tối đa, công thức tính tiền phạt, công thức tính tiền điện…) Sản phẩm có thể mở
rộng, tăng cường về mặt chức năng một cách dễ dàng.
 Tính hiệuquả
Tính hiệu quả của một sản phẩm phần mềm được xác định qua các tiêu chuẩn
sau:
- Hiệu quả kinh tế hoặc ý nghĩa, giá trị thu được do áp dụng sản phẩmđó.
- Tốc độ xử lý của phần mềm (v) tính bằng tỉ lệ giữa khối lượng đối tượng

cần phải xử lý (m) và tổng thời gian (t) cần thiết để xử lý các đối tượngđó. Sử dụng
tối ưu tài nguyên của máy tính (CPU, bộnhớ…)
 Tính tiệndụng
Sản phẩm phải tính đến những yếu tố tâm lý sau đây của người dùng:

- Dễ học, có giao diện trực quan tựnhiên.
- Dễ thaotác

 Tính tươngthích
Trao đổi dữ liệu với các phần mềm khác có liên quan (nhận danh mục sách từ
tập tin Excel, gửi báo cáo tổng kết năm học đến phần mềm WinFax.
- Giao tiếp nộibộ
- Giao tiếp bênngoài

 Tính tái sửdụng
Sản phẩm phần mềm có thể áp dụng cho nhiều lĩnh vực theo nhiều chế độ làm
việc khác nhau.
- Các phần mềm cùnglớp
- Các phần mềm kháclớp
1.2

Các mô hình phát triển phần mềm

1.2.1Mô hình thác nước
Có tên gọi là “mô hình thác nước”, khuôn cảnh vòng đời yêu cầu một cách
tiếp cận tuần tự đối với việc phát triển phần mềm. Nó bắt đầu ở mức hệ thống và
6


tiến dần xuống phân tích, thiết kế, mã hóa, kiểm thử và bảo trì. Như vậy khuôn cảnh
vòng đời bao gồm các hoạt động trong mô hình thác nước sau:
1. Kỹ nghệ và phân tích hệ thống: Phần mềm là một phần của hệ thống ứng
dụng nên công việc phải bắt đầu từ việc thiết lập yêu cầu cho tất cả các phần tử của
hệ thống. Kỹ nghệ và phân tích hệ thống bao gồm việc thu thập yêu cầu ở mức hệ
thống với một thiết kế sơ bộ và phân tích mức đỉnh.

2. Phân tích yêu cầu phần mềm: Tiến trình thu thập yêu cầu được tập trung và
làm mạnh đặc biệt vào phần mềm. Các kỹ sư phần mềm cần phải diễn đạt ra được
các yêu cầu đối với phần mềm dưới dạng các chức năng cần có, hiệu năng và giao
diện. Cần lập tư liệu về các yêu cầu cho cả hệ thống và phần mềm, và được khách
hàng duyệt lại.
3. Thiết kế: Thiết kế phần mềm là một tiến trình nhiều bước tập trung vào bốn
thuộc tính phân biệt của chương trình:
- Thiết kế cấu trúc dữ liệu
- Kiến trúc phần mềm (các chức năng của chương trình)
- Chi tiết các thủ tục, thuật tóan
- Thiết kế giao diện
Tiến trình thiết kế chuyển hóa các yêu cầu thành một biểu diễn của phần mềm
có thể khẳng định về chất lượng trước khi giai đoạn mã hóa bắt đầu.Việc thiết kế
phải được lập tư liệu và trở thành một phần của cấu hình phần mềm.

7


Kỹ nghệ hệ
thống
Phân tích và ðịnh rõ
yêu cầu

Thiết kế hệ thống
và thiết kế phần
mềm
Mã hoá

Kiểm thử ðơn vị/
tích hợp /hệ thống

Vận hành
và bảo trì

4. Mã hóa: dùng một ngôn ngữ lập trình cụ thể viết chương trình. Đây là khâu
quan trọng và tốn kém nhất về thời gian và chất xám của cán bộ lập trình – chuyên
gia phần mềm.
5. Kiểm thử: Việc kiểm thử bắt đầu sau khi đã sinh ra mã, tập trung vào phần
logic bên trong chương trình, đảm bảo rằng tất cả các câu lệnh đều được kiểm thử.
Về phần chức năng bên ngoài cần đảm bảo việc tiến hành kiểm thử phát hiện ra các
lỗi và đảm bảo những cái vào xác định sẽ tạo ra kết quả thực tế thống nhất với kết
quả muốn có.Việc kiểm thử luôn đi liền với việc viết mã, xong một thủ tục phải thử
ngay để sửa lỗi.
6. Bảo trì: Phần mềm chắc chắn sẽ có những thay đổi sau khi được bàn giao
cho khách hàng (ngoại lệ là những phần mềm nhúng). Nguyên nhân có thể là lỗi do
phần mềm, phải thích ứng với môi trường bên ngoài (hệ điều hành mới, thiết bị
ngoại vi mới...), hoặc do khách hàng yêu cầu nâng cao chức năng hay hiệu năng…
Việc bảo trì phần mềm phải áp dụng lại các bước vòng đời nói trên.
Vòng đời cổ điển ra đời sớm nhất và được sử dụng rộng rãi nhất cho kỹ nghệ
phần mềm. Tuy nhiên có một số vấn đề hay gặp phải:

8


- Các dự án hiếm khi tuân theo dòng chảy tuần tự mà mô hình đề ra. Việc lặp
lại bao giờ cũng xuất hiện và gây ra vấn đề.
- Khách hàng khó phát biểu hết mọi yêu cầu một cách tường minh khi mới
triển khai dự án và thường xẩy ra mâu thuẫn giữa thực tế với khả năng đáp ứng của
phần mềm.
1.2.2 Mô hình nguyên mẫu
Thông thường khách hàng đã xác định được mục tiêu tổng quát của phần

mềm, nhưng chưa xác định được dữ liệu nào cần nhập vào, xử lý ra sao hay dữ liệu
xuất ra như thế nào, người phân tích chưa hiểu rõ nhu cầu của khách hàng. Ngoài
ra, người phát triển có thể không chắc về tính hiệu quả của một thuật toán hay giải
pháp, việc thích nghi hệ điều hành hay dạng giao diện người máy (HCI – Human
Computer Interface) cần có. Trong những trường hợp này và nhiều trường hợp khác
cách tiếp cận làm bản mẫu cho kỹ nghệ phần mềm là tốt nhất.
Làm bản mẫu là một tiến trình có khả năng tạo ra một mô hình cho phần mềm
cần phải xây dựng. Mô hình có thể ở trong 3 dạng:
(1)

bản mẫu trên giấy hay mô hình dựa trên máy PC mô tả giao diện người

máy dưới dạng làm cho người dùng hiểu được cách các tương tác xuất hiện
(2)

bản mẫu làm việc cài đặt một tập con các chức năng của phần mềm

mong muốn
(3)

một chương trình đã có thực hiện một phần hay tất cả các chức năng

mong muốn nhưng cần phải cải tiến thêm các tính năng khác tùy theo khả năng phát
triển.

9


Bắt ðầu

Kết thúc

Tập hơp yêu cầu &
làm mịn, xác ðịnh
mục tiêu tổng thể,
khảo sát thêm ðể
ðịnh rõ yêu cầu

Sản phẩm

Làm
mịn bản
mẫu

Vi chỉnh
Bản Mẫu

Thiết kế
nhanh
(inpu,
out put)
Xây dựng
bản mẫu

Ðánh giá của
khách hàng
về bản mẫu

Dãy các sự kiện của khuôn cảnh làm bản mẫu được minh họa trong hình sau:
Giống như các mọi cách tiếp cận cho việc phát triển phần mềm, việc làm bản

mẫu bắt đầu với việc thu thập yêu cầu. Người phát triển và khách hàng gặp nhau,
xác định các mục tiêu tổng thể cho phần mềm, xác định các yêu cầu nào đã biết,
miền nào bắt buộc phải xác định thêm.Rồi đến việc “thiết kế nhanh” để xây dựng
một bản mẫu.Bản mẫu được người dùng đánh giá và được dùng để làm mịn các yêu
cầu đối với phần mềm cần phát triển. Tiến trình lặp đi lặp lại xảy ra để cho bản mẫu
được “vi chỉnh” thỏa mãn nhu cầu của khách hàng, đồng thời giúp người phát triển
hiểu kỹ hơn cần phải thực hiện nhu cầu nào. Giống như vòng đời cổ điển, việc làm
bản mẫu tựa như một khuôn cảnh cho kỹ nghệ phần mềm có thể trở thành có vấn
đề.
1.2.3 Mô hình xoắn ốc
Mô hình xoắn ốc bao gồm các tính năng tốt nhất của cả vòng đời cổ điển lẫn
làm bản mẫu, trong khi còn bổ xung yếu tố mới là phân tích rủi ro – cái còn thiếu
trong các mô hình này.Mô hình này được biểu diễn theo đường xoắn ốc, xác định ra
bốn hoạt động chính:

10


(1)

Lp k hoch: xỏc nh mc tiờu, gii phỏp v rng buc

(2)

Phõn tớch ri ro: phõn tớch cỏc phng ỏn v xỏc nh, gii quyt ri ro.

(3)

K ngh: phỏt trin sn phm mc tip

(4)

ỏnh giỏ ca khỏch hng: khng nh kt qu ca k ngh

Kế hoạch

Phân tích rủi ro

(I)

(II)

Tập hợp yêu cầu
ban đầu và
lp kế hoạch dự án

Phân tích rủi ro
dựa trên yêu cầu
ban đầu
Phân tích rủi ro dựa trên
phản ứng của khách hàng

Kế hoạch
dựa trên ý kiến
khách hàng

(Quyết định tiếp hay không)

Hớng tới hệ thống hoàn chỉnh
Đánh giá của

khách hàng

Bản mẫu ban đầu
Bản mẫu tầng tiếp theo

(IV)

Bn mu n

(III)

Mi ln lp xung quanh xon c (t tõm i ra ngoi) ngi ta li xõy dng
thờm cỏc phiờn bn c hon thin dn ca phn mm. Trong mch xon th nht,
cỏc mc tiờu, phng phỏp, rng buc, cỏc ri ro c nh rừ v phõn tớch. Nu
phõn tớch ri ro ch ra rng, khụng chc chn trong cỏc yờu cu thỡ vic lm bn mu
cú th c s dng trong gúc phn t k ngh.Cỏc mụ phng v cỏc mụ hỡnh khỏc
cng cú th c dựng xỏc nh rừ thờm vn v lm mn yờu cu.
Khỏch hng ỏnh giỏ cụng vic k ngh v a ra gi ý v nhng thay i
(gúc phn t ỏnh giỏ ca khỏch hng), giai on tip ca vic lp k hoch v phõn
tớch ri ro s c tin hnh. Ti mi vũng xung quanh xon c, cao im ca vic
phõn tớch ri ro l tin hnh hay khụng tin hnh, nu ri ro quỏ ln cú th ỡnh
ch d ỏn.
Mi mch i xung quanh xon c u ũi hi k ngh (gúc phn t phớa di
bờn phi) cú th c thc hin bng cỏch tip cn vũng i v lm bn mu. Tt
11


nhiên số các hoạt động phát triển xuất hiện trong góc phần tư phía dưới bên phải
tăng lên khi các hoạt động chuyển xa hơn ra khỏi trung tâm xoắn ốc.
Khuôn cảnh mô hình xoắn ốc đối với kỹ nghệ phần mềm hiện tại là cách tiếp

cận thực tế nhất đến việc phát triển cho các hệ thống và phần mềm quy mô
lớn.Trong đó người ta dùng cách làm bản mẫu như một cơ chế làm giảm bới rủi ro.
Mô hình này tương đối mới và còn chưa được sử dụng rộng rãi như vòng đời, làm
bản mẫu.
1.2.4 Mô hình hợp nhất
Các khuôn cảnh đề cập ở trên được mô tả như các cách tiếp cận khác nhau đối
với kỹ nghệ phần mềm chứ không phải là cách tiếp cận bổ xung cho nhau, tuy nhiên
trong nhiều trường hợp có thể và cũng nên tổ hợp các khuôn cảnh để đạt sức mạnh
của từng khuôn cảnh cho một dự án riêng lẻ.
Hình dưới minh họa cách tổ hợp các khuôn cảnh kỹ nghệ phần mềm, trong
mọi trường hợp, công việc bắt đầu với mọi khuôn cảnh là việc xác định mục tiêu,
phương án và các ràng buộc (hay thu thập yêu cầu sơ bộ). Từ điểm này, bất kỳ một
con đường nào trên hình đều có thể được chọn.

12


Phân tích yêu cầu

Tập hợp các yêu cầu ban ðầu

Thiết kế

Mã hoá

Làm bản mẫu

Bản mẫu: vòng thứ
n

4GT

Mô hình xoắn ốc

4GT

Mô hình xoắn ốc:
vòng thứ n
Kiểm thử
4GT

Hệ thống hoạt dộng

Bảo trì

Chẳng hạn, nếu có thể xác định được hoàn toàn hệ thống ngay từ đầu, có thể
đi theo bước vòng đời cổ điển, nếu các yêu cầu còn chưa được chắc chắn thì có thể
sử dụng bản mẫu như một bản hướng dẫn, người phát triển có thể trở lại các bước
của vòng đời cổ điển (thiết kế, mã hóa, kiểm thử). Bản mẫu có thể tiến hóa thành hệ
thống sản xuất, với việc quay trở về khuôn cảnh vòng đời để kiểm thử.
Các kỹ thuật thứ tư có thể dùng để cài đặt bản mẫu hay cài đặt hệ thống sản
xuất trong bước mã hóa của vòng đời. 4GT có thể được dùng kèm với mô hình xoắn
ốc cho các bước làm bản mẫu hay mã hóa.
Không nên cứng nhắc trong việc chọn khuôn cảnh cho kỹ nghệ phần
mềm.Dựa vào bản chất của ứng dụng mà ấn định ra cách tiếp cận cần được chọn
13


bằng cách tổ hợp các cách tiếp cận thì ích lợi một tổng thể sẽ còn lớn hơn là tổng
thể của từng phần.

1.2.5 Mô hình phát triển ứng dụng nhanhRAD (Rapid Application
Development)
- Là quy trình phát triển phần mềm gia tăng, tăng dần tùng bước (Incrimental

software development) với mỗi chu trình phát triển rất ngắn (60-90 ngày)
- Xây dựng đưa trên hướng thành phần (Component-based construction) với

khả năng tái sử dụng (reuse)
- Gồm một số nhóm (teams), mỗi nhóm làm 1 RAD theo các pha: Mô hình

nghiệp vụ, mô hình dữ liệu, mô hình xử lý, tạo ứng dụng, kiểm thử và đánh giá
(Business, Data, Process, Appl, Generation,Test)

14


Mô hình RAD

- Rapid Application Development là mô hình tuần tự tuyến tính có thời
gian phát triển rất ngắn
- Sủ dụng các thành phần có sẵn càng nhiều càng tốt
- Sử dụng công cụ lập trình ở dạng tự động sinh mã chứ không phải các ngôn
ngữ truyền thống
RAD: Business modeling
Luồng thông tin được mô hình hóa để trả lời các câu hỏi :
- Thông tin nào điều kiển xử lý nghiệp vụ
- Thông tin gì được sinh ra
- Ai sinh ra nó
- Thông tin đi đến đâu
- Ai xử lý chúng

RAD: Data and Process modeling
- Data modeling: Các đối tượng dữ liệu cần để hổ trợ nghiệp vụ (business).
Định nghĩa các thuộc tính của từng đối tượng và xác lập quan hệ giữa các đối tượng
- Process modeling: Các đối tượng dữ liệu được triển sang luồng thông tin
thực hiện chức năng nghiệp vụ. Tạo mô tả xử lý để cập nhật (thêm, sửa, xóa, khôi
phục) từng đối tượng dữ liệu
RAD: Application Generation and Testing
- Application Generation: Dùng các kỹ thuật thế hệ 4 để tạo phần mềm từ các
thành phần có thể tái dụng lại sau này.Dùng các công cụ tự đông để xây dựng phần
mềm
- Testing and Turnover : Kiểm thử các thành phần mới và kiểm chứng mọi
giao điện ( các thành phần cũ đã được kiểm thử và dùng lại)
RAD: Hạn chế
- Cần nguồn nhân lực đồi đào để tạo các nhóm cho các chức năng chính

15


- Yêu cầu hai bên giao kèo trong thời gian ngắn phải có phần mềm hoàn
chính, thiếu trách nhiệm của một bên để làm được dự án đổ vỡ
- RAD không phải tốt cho mọi ứng dụng, nhất là với ứng dụng không thể mô
dun hóa hoặc đòi hỏi tính năng cao
- Mạo hiểm kỹ thuật cao thì không nên dùng RAD
1.3 Các hoạt động phát triển phần mềm
1.3.1 Xác định yêu cầu
Trong những lần gặp đầu tiên giữa khách hàng và người phát triển, khách hàng
phác thảo các yêu cầu, chức năng, các công việc cần thực hiện của phần mềm mà họ
muốn đặt hàng. Theo cách nhìn nhận của người phát triển thì những điều khách
hàng mô tả có thể mơ hồ, có những điều không hợp lý, thậm chí mâu thuẫn hay
không khả thi. Nhiệm vụ của người phát triển là phải tìm hiểu xem thực chất khách

hàng cần gì. Ngoài những yêu cầu về chức năng và công việc, họ còn phải tìm hiểu
xem các điều kiện về phần mềm là gì? Ví dụ như phần mềm phải hoàn thành trong
thời gian bao lâu, phần mềm cần làm việc với hệ điều hành nào, trên máy tính có
cấu hình ra sao, giá cả khoảng bao nhiêu thì chấp nhận được. Thường thì chính
khách hàng hỏi lại người phát triển giá của phần mềm, và người phát triển phải cân
nhắc khi trả lời câu hỏi này.
Những khảo sát ban đầu về nhu cầu khách hàng được gọi là tìm hiểu vấn đề
(concept exploration). Các buổi gặp tiếp theo sẽ bàn kỹ hơn về các chức năng của
phần mềm, các vấn đề kỹ thuật liên quan và kinh phí.
Thường thì mọi việc trong pha xác định yêu cầu có vẻ như được thực hiện
suôn sẻ. Khách hàng và người phát triển hiểu nhau, công việc được chuyển qua pha
tiếp theo. Tuy nhiên thực tế lại chứng tỏ rằng, thường thì pha xác định yêu cầu
không được thành công lắm. Sau này khi sản phẩm được cài đặt và đưa vào sử
dụng, khách hàng bỗng đến gặp những người phát triển và phàn nàn rằng "quả tình
là các anh đã làm đúng những gì tôi yêu cầu, nhưng bây giờ tôi mới nhận ra là có lẽ
phần mềm tôi cần lại không hẳn là cái mà các anh đã xây dựng". Trong những
trường hợp này, phần mềm lại phải sửa đổi, các tài liệu phải viết lại,... Những tình
huống trên đây rất hay xảy ra trong các trường hợp khách hàng hiểu biết ít về máy

16


tính. Lúc này người phát triển và khách hàng thường bị "bất đồng ngôn ngữ". Để
khắc phục tình trạng này, người phát triển thường viết nhanh một phần mềm thực
hiện những điều mà khách hàng yêu cầu. Trong phần mềm này chưa cần giao diện
đẹp, chưa cần kiểm tra nhập dữ liệu,...cốt là để khách hàng có thể dùng thử xem nó
có thực hiện đúng những điều họ muốn không. Phiên bản thử nghiệm này được gọi
là bản mẫu nhanh (rapid prototype). Phương pháp xác định yêu cầu sử dụng bản
mẫu được gọi là kỹ thuật dùng bản mẫu.
1.3.2 Phân tích (đặc tả)

Khi khách hàng cho rằng nhóm phát triển đã hiểu được các yêu cầu của họ thì
công việc được chuyển sang pha đặc tả. Nhóm đặc tả (hay phân tích) sẽ biên soạn
tài liệu đặc tả. Những điều được nêu trong tài liệu của pha yêu cầu sẽ được chi tiết
và chính xác hóa. Các chức năng của phần mềm được mô tả một cách rõ ràng,
tường minh. Những điều kiện ràng buộc về phần mềm được liệt kê đầy đủ. Tài liệu
đặc tả còn chỉ rõ đầu vào (input) và đầu ra (output) của phần mềm. Ví dụ, nếu yêu
cầu của khách hàng là phần mềm tính bảng lương của một cơ quan thì đầu vào là
các mức lương của mỗi nhân viên, bảng ghi các ngày làm việc, các thông tin về
thuế thu nhập của từng người... Đầu ra là bảng lương cùng với báo cáo về phần
khấu trừ vào bảo hiểm xã hội, bảo hiểm y tế...Báo cáo đặc tả là cơ sở tạo ra bản hợp
đồng. Hay nói chính xác hơn, báo cáo đặc tả là những điều kiện của bản hợp đồng.
Những người phát triển phần mềm sẽ được coi như hoàn thành hợp đồng nếu sản
phẩm thỏa mãn các tiêu chuẩn nêu ra trong bản đặc tả. Chính vì vậy bản đặc tả
không chứa những từ không có ý nghĩa chính xác như: nói chung, thích hợp, tương
đối, phong phú... Tài liệu đặc tả phải được viết sao cho có thể sử dụng như là chứng
cứ khi có vấn đề cần đưa ra phân xử ở tòa án, ngay cả khi phần mềm được viết để
sử dụng trong nội bộ một cơ quan (và như vậy khả năng kiện tụng sẽ không xảy ra).
Tài liệu đặc tả đóng vai trò quan trọng trong việc kiểm thử và bảo trì phần mềm. Ta
có thể căn cứ vào tài liệu này để kiểm tra xem phần mềm đã thỏa mãn các mục tiêu
đặt ra chưa. Nếu nhu cầu khách hàng thay đổi thì phần nào của tài liệu đặc tả cần
thay đổi cho phù hợp...
Các thiếu sót sau có thể xảy ra trong pha đặc tả:

17


- Một lỗi mà nhóm đặc tả thường vi phạm là diễn tả vấn đề không chính xác,
đôi lúc có thể hiểu nhiều nghĩa. Ví dụ: sắp xếp mảng A rồi chọn phần tử đầu tiên.
Ở đây từ sắp xếp chưa cho cách hiểu duy nhất, sắp tăng dần hay giảm dần?
- Tài liệu chưa đầy đủ: Ví dụ nếu dữ liệu có lỗi thì giải quyết như thế nào?

Sau khi tài liệu đặc tả được biên soạn xong thì tiếp theo là xây dựng kế hoạch
chi tiết và ước lượng thời gian hoàn thành và giá trị phần mềm. Khách hàng sẽ
không chấp nhận dự án phần mềm nếu chưa biết các thông tin là dự án sẽ kéo dài
trong bao lâu và chi phí hết bao nhiêu. Các vấn đề này rất khó. Nếu giá cả thấp thì
công ty bị thiệt, cao thì có thể khách hàng lại chọn một công ty khác chấp nhận giá
rẻ hơn. Nếu thời gian ước lượng quá ngắn, không kịp hoàn thành thì công ty phần
mềm hoặc bị mất lòng tin đối với khách hàng, hoặc nếu khách hàng kiện thì có thể
bị phạt. Nếu thời hạn hoàn thành quá dài thì khách hàng có thể chọn đối tác khác
làm nhanh hơn. Ngoài việc ước lượng thời gian và giá cả, những người phát triển
còn phải phân công nhân sự một cách thích hợp cho từng giai đoạn. Ví dụ nhóm
viết chương trình chưa thể bắt đầu khi các tài liệu thiết kế chưa được nhóm SQA
kiểm tra và chấp nhận. Nhóm thiết kế lại không thể bắt đầu công việc nếu nhóm đặc
tả chưa hoàn thành công việc của họ. Tóm lại, kế hoạch quản lý dự án phần mềm
(SPMP) cần được biên soạn kỹ lưỡng nhằm phản ánh các giai đoạn khác nhau của
quá trình phát triển phần mềm, những thành viên tham gia trong từng giai đoạn và
thời hạn cần hoàn thành.
Thời điểm sớm nhất để bắt đầu xây dựng SPMP là khi phần đặc tả kết thúc.
Trước đó thì dự án vẫn chưa định hình nên không thể viết kế hoạch được. Dĩ nhiên
cũng có những phần của dự án có thể lập kế hoạch sớm hơn, có thể ngay khi bắt
đầu; tuy nhiên cho đến khi những người phát triển xác định được là cần xây dựng
cái gì thì họ không thể xem xét mọi khía cạnh của dự án và xây dựng kế hoạch
được.
Những thành phần chính của kế hoạch là: những phần sản phẩm chuyển giao
cho khách hàng, các mốc thời gian cần chuyển giao, chi phí của các phần sản phẩm
này.

18


Bản kế hoạch mô tả tỉ mỉ quy trình phần mềm bao gồm: mô hình vòng đời

phần mềm được sử dụng, cơ cấu tổ chức của công ty phần mềm, những mục tiêu
của dự án, các kỹ thuật và các công cụ CASE được sử dụng, lịch trình làm việc chi
tiết, chi phí ..
1.3.3 Thiết kế
Pha đặc tả cho chúng ta biết "phần mềm làm gì?", còn pha thiết kế lại trả lời
câu hỏi "làm như thế nào?" Với việc tìm hiểu nghiên cứu bản báo cáo đặc tả, nhóm
thiết kế xác định cấu trúc bên trong của phần mềm. Họ phân chia phần mềm thành
các module, là những phần mã lệnh độc lập nhau và có các giao tiếp phù hợp với
các phần còn lại của phần mềm. (Đối tượng cũng là một trường hợp đặc biệt của
module). Các giao tiếp của một module là các tham số vào và các tham số ra của nó.
Ví dụ nếu module là tính lãi suất tiết kiệm thì đầu vào là số tiền gửi, thời gian gửi,
loại tiết kiệm (không kỳ hạn, 3 tháng, 6 tháng hay 1 năm...) và đầu ra là số tiền lãi.
Sau khi kết thúc việc phân chia phần mềm thành các module (thiết kế kiến
trúc), nhóm làm việc bắt đầu công việc thiết kế chi tiết cho từng module. Với mỗi
module cần chọn các thuật toán và các cấu trúc dữ liệu thích hợp. Trong quá trình
phân chia phần mềm thành các module, nhóm làm việc cần ghi chép lại các bước
quyết định và lý do lựa chọn. Làm như vậy có hai điều lợi:
Thứ nhất, có thể đôi khi công việc đi đến chỗ bế tắc, người ta phải quay lại và
sửa đổi một số quyết định của các bước trước đó. Nếu có bản ghi chép đầy đủ thì
việc quay lại này dễ dàng hơn.
Thứ hai, việc ghi chép đầy đủ sẽ rất tốt cho công tác bảo trì. Chúng ta biết
rằng phần mềm không bao giờ giữ nguyên mà thường hay bị sửa đổi. Một phần
mềm tốt phải có tính mở (open-ended), có nghĩa là ta có thể thêm vào, bớt đi hoặc
thay đổi một số module mà không phải thay đổi nhiều các phần còn lại. Tuy nhiên
điều này trong thực tế rất khó thực hiện. Do sức ép về thời gian, nhóm làm việc chủ
yếu tập trung vào việc thiết kế phần mềm theo các yêu cầu hiện có mà ít khi suy
nghĩ đến việc mở rộng nâng cấp trong tương lai. Nhóm làm việc thường chọn sự
thỏa hiệp là thiết kế và ghi chép lại sao cho sau này khi cần nâng cấp phần mềm thì
biết được cần thay đổi module nào, sao cho sự sửa đổi càng ít càng tốt. Thậm chí

19


ngay cả trong trường hợp phần mềm phải thiết kế lại hoàn toàn thì bản thiết kế cũ
với ghi chép đầy đủ cũng sẽ cung cấp nhiều thông tin bổ ích.
1.3.4 Cài đặt
Cài đặt là quá trình chuyển đổi thiết kế chi tiết thành các mã chương trình.Nói
như cách thông thường là viết chương trình thực hiện những điều nêu ra trong bản
thiết kế. Nếu chương trình chỉ do một người viết thì quá trình này tương đối dễ hiểu.
Tuy nhiên, ngày nay phần mềm cần xây dựng thường rất lớn, và do đó phải được
thực hiện bởi nhiều người.Vì vậy người ta sử dụng thuật ngữ "lập trình bởi nhiều
người" (programming-in-the-many) để chỉ cách lập trình gồm nhiều người tham gia.
Cho đến nay ta vẫn xem cài đặt và tích hợp là hai pha riêng biệt, độc lập lẫn nhau.
Mỗi module (đối tượng cũng được xem là module) sẽ được cài đặt (viết code) bởi
một thành viên của nhóm lập trình và được kiểm thử bởi nhóm bảo đảm chất lượng
phần mềm.Trong quá trình tích hợp thì các module được hợp lại và được kiểm thử
một cách tổng thể.Thực ra người ta thấy rằng cách này không phải là hiệu quả nhất
để phát triển phần mềm. Người ta thấy rằng hai pha cài đặt và tích hợp nên được
thực hiện song song thì tốt hơn. Vì vậy người ta thường gộp hai pha này và gọi
chung là "pha cài đặt và tích hợp". Thực ra thì cài đặt và tích hợp là hai hoạt động
khác hẳn nhau.Trong chương này chúng ta sẽ xem xét các hoạt động này khi chúng
được thực hiện đồng thời, hay chính xác hơn là đan xen nhau.Trước hết chúng ta sẽ
xem xét đến việc lựa chọn ngôn ngữ để cài đặt chương trình.
1.3.5 Kiểm thử
Kiểm thử phần mềm là tiến hành thí nghiệm để so sánh kết quả thực tế với lý
thuyết nhằm mục đích phát hiện lỗi.Bộ thử nghiệm (test cases) là dữ liệu dùng để
kiểm tra hoạt động của chương trình.Một bộ kiểm thử tốt là bộ có khả năng phát
hiện ra lỗi của chương trình.Khi tiến hành kiểm thử, chúng ta chỉ có thể chứng minh
được sự tồn tại của lỗi nhưng không chứng minh được rằng trong chương trình
không có lỗi.

Mục đích của chúng ta là thiết kế các phép kiểm thử để làm lộ ra một cách có
hệ thống những lớp lỗi khác nhau trong một số lượng thời gian và công sức tối
thiểu.

20


Nếu kiểm thử được tiến hành thành công thì nó sẽ làm lộ ra những lỗi trong
phần mềm. Xem như một lợi ích phụ, kiểm thử chứng tỏ rằng các chức năng phần
mềm làm việc theo đặc tả, các yêu cầu hiệu năng là được đáp ứng, đưa ra một chỉ
dẫn tốt về độ tin cậy của chất lượng phần mềm.
Điều quan trọng là cần nhớ phát biểu sau trong tâm khi tiến hành kiểm thử:
“Kiểm thử không thể chứng minh được việc không có khiếm khuyết, nó chỉ có thể
chứng minh rằng khiếm khuyết phần mềm hiện hữu”
1.3.6 Bảo trì
Nếu phần mềm được chấp nhận bởi khách hàng và cài đặt trên máy của họ thì
từ lúc đó mọi thay đổi về phần mềm đều được gọi là bảo trì. Bảo trì là một phần của
quy trình phần mềm và thường có chi phí lớn hơn tất cả các pha khác cộng lại. Một
vấn đề quan trọng hay bị lãng quên trong pha bảo trì là vấn đề cập nhật tài liệu. Mỗi
khi có thay đổi về phần mềm trong pha bảo trì thì đáng lẽ các tài liệu trong các pha
trước đó đều phải sửa đổi. Tuy nhiên người ta thường không làm điều này và tài liệu
trong pha bảo trì thường chỉ có mã nguồn của phần mềm đã sửa đổi. Trong nhiều
trường hợp, thời gian bảo trì khá dài và có thể những người xây dựng nên phần
mềm không còn ở công ty nữa, và việc bảo trì càng trở nên khó khăn. Nói chung
pha bảo trì là pha trải qua nhiều thách thức nhất trong quá trình sản xuất phần mềm.
1.4 Các kỹ thuật tiếp cận trong phát triển phần mềm
Để thực hiện một dự án phát triển phần mềm thì vấn đề quan trọng đầu tiên là
phải chọn cho được một cách thực hiện thích hợp dựa trên những mô hình phát
triển. Có hai cách tiếp cận cơ bản để phát triển phần mềm: cách tiếp hướng chức
năng và cách tiếp cận hướng đối tượng.

1.4.1 Cách tiếp cận hướng chức năng
Phần lớn các chương trình được viết bằng ngôn ngữ lập trình như C, hay
Pascal từ trước đến nay đều được thực hiện theo cách tiếp cận hướng chức năng hay
còn được gọi là cách tiếp cận hướng thủ tục. Cách tiếp cận này có những đặc trưng
sau:

• Dựa vào chức năng, nhiệm vụ là chính

21


Khi khảo sát, phân tích một hệ thống chúng ta thường tập trung vào các
nhiệm vụ mà nó cần thực hiện. Chúng ta tập trung trước hết nghiên cứu các yêu cầu
của bài toán để xác định các chức năng chính của hệ thống. Ví dụ khi cần xây dựng
“hệ thống quản lý thư viện” thì trước hết chúng ta thường đi nghiên cứu, khảo sát
trao đổi và phỏng vấn xem những người thủ thư, bạn đọc cần phải thực hiện những
công việc gì để phục vụ được bạn đọc và quản lý tốt được các tài liệu. Qua nghiên
cứu “hệ thống quản lý thư viện”, chúng ta xác định được các nhiệm vụ chính của hệ
thống như: quản lý bạn đọc, cho mượn sách, nhận trả sách, thông báo nhắc trả sách,
Như vậy, khi đã nghiên cứu để hiểu rõ được bài toán và xác định được các yêu cầu
của hệ thống thì các chức năng, nhiệm vụ của hệ thống gần như là không thay đổi
suốt trong quá trình phát triển tiếp theo ngoại trừ khi cần phải khảo sát lại bài toán.
Dựa chính vào chức năng (thuật toán) thì dữ liệu sẽ là phụ và biến đổi theo các chức
năng. Do đó, hệ thống phần mềm được xem như là tập các chức năng, nhiệm vụ cần
tổ chức thực thi.

• Phân rã chức năng và làm mịn dần theo cách thực hiện từ trên xuống
Khả năng của con người là có giới hạn khi khảo sát, nghiên cứu để hiểu và
thực thi những gì mà hệ thống thực tế đòi hỏi. Để thống trị (quản lý được) độ phức
tạp của những vấn đề phức tạp trong thực tế thường chúng ta phải sử dụng nguyên

lý chia để trị, nghĩa là phân tách nhỏ các chức năng chính thành các chức năng đơn
giản hơn theo cách từ trên xuống. Quá trình này được lặp lại cho đến khi thu được
những đơn thể chức năng tương đối đơn giản, hiểu được và thực hiện cài đặt chúng
mà không làm tăng thêm độ phức tạp để liên kết chúng trong hệ thống. Độ phức tạp
liên kết các thành phần chức năng của hệ thống thường là tỉ lệ nghịch với độ phức
tạp của các đơn thể. Vì thế một vấn đề đặt ra là có cách nào để biết khi nào quá trình
phân tách các đơn thể chức năng hay còn gọi là quá trình làm mịn dần này kết thúc.
Thông thường thì quá trình thực hiện phân rã các chức năng của hệ thống phụ
thuộc nhiều vào độ phức hợp của bài toán ứng dụng và vào trình độ của những
người tham gia phát triển phần mềm. Một hệ thống được phân tích dựa trên các
chức năng hoặc quá trình sẽ được chia thành các hệ thống con và tạo ra cấu trúc

22


phân cấp các chức năng. Ví dụ, hệ thống quản lý thư viện có thể phân chia từ trên
xuống như sau:
Hệ thống quản lý thý viện

Quản lý bạn ðọc

Cho mýợn tài liệu

Nhận trả tài liệu

Nhắc trả tài liệu

Hình 1.1: Sõðồ chức nãng của Hệ thống quản lý thý viện
Chúng ta có thể khẳng định là các chức năng của nhiều hệ thống thông tin quản lý
đều có thể tổ chức thành sơ đồ chức năng theo cấu trúc phân cấp có thứ bậc.

• Các đơn thể chức năng trao đổi với nhau bằng cách truyền tham số hay
sử dụng dữ liệu chung
Một hệ thống phần mềm bao giờ cũng phải được xem như là một thể thống
nhất, do đó các đơn thể chức năng phải có quan hệ trao đổi thống tin, dữ liệu với
nhau. Trong một chương trình gồm nhiều hàm (thực hiện nhiều chức năng khác
nhau) muốn trao đổi dữ liệu được với nhau thì nhất thiết phải sử dụng dữ liệu liệu
chung hoặc liên kết với nhau bằng cách truyền tham biến. Mỗi đơn thể chức năng
không những chỉ thao tác, xử lý trên những biến dữ liệu cục bộ mà còn phải sử dụng
các biến chung, thường đó là các biến toàn cục.
Dữ liệu chung

Dữ liệu chung

Chức nãng 1

Chức nãng 2

Dữ liệu riêng

Dữ liệu riêng

Hình 1.2: Mối quan hệ giữa các chức nãng trong hệ thống

23


Với việc sử dụng những biến toàn cục thì những bất lợi trong quá trình thiết kế
và lập trình là khó tránh khỏi. Đối với những dự án lớn, phức tạp có nhiều nhóm
tham gia, mỗi nhóm chỉ đảm nhận một số chức năng nhất định và như thế khi một

nhóm có yêu cầu thay đổi về dữ liệu chung đó thì sẽ kéo theo tất cả các nhóm khác
có liên quan cũng phải thay đổi theo. Kết quả là khi có yêu cầu thay đổi của một
đơn thể chức năng sẽ ảnh hưởng tới các chức năng khác và do đó sẽ ảnh hưởng tới
hiệu xuất lao động của các nhóm cũng như của cả dự án. Mặt khác, các chức năng
của hệ thống có nhu cầu phải thay đổi là tất yếu và rất thường xuyên.

• Tính mở và thích nghi của hệ thống được xây dựng theo cách tiếp cận
này là thấp vì:
Hệ thống được xây dựng dựa vào chức năng là chính mà trong thực tế thì
chức năng, nhiệm vụ của hệ thống lại hay thay đổi. Để đảm bảo cho hệ thống thực
hiện được công việc theo yêu cầu, nhất là những yêu cầu về mặt chức năng đó lại bị
thay đổi là công việc phức tạp và rất tốn kém. Ví dụ: giám đốc thư viện yêu cầu
thay đổi cách quản lý bạn đọc hoặc hơn nữa, yêu cầu bổ sung chức năng theo dõi
những tài liệu mới mà bạn đọc thường xuyên yêu cầu để đặt mua, v.v. Khi đó vấn đề
duy trì hệ thống phần mềm không phải là vấn đề dễ thực hiện. Nhiều khi có những
yêu cầu thay đổi cơ bản mà việc sửa đổi không hiệu quả và vì thế đòi hỏi phải thiết
kế lại hệ thống thì hiệu quả hơn.
Các bộ phận của hệ thống phải sử dụng biến toàn cục để trao đổi với nhau,
do vậy khả năng thay đổi, mở rộng của chúng và của cả hệ thống là bị hạn chế. Như
trên đã phân tích, những thay đổi liên quan đến các dữ liệu chung sẽ ảnh hưởng tới
các bộ phận liên quan. Do đó, một thiết kế tốt phải rõ ràng, dễ hiểu và mọi sửa đổi
chỉ có hiệu ứng cục

• Khả năng tái sử dụng bị hạn chế và không hỗ trợ cơ chế kế thừa.
Để có độ thích nghi cao thì mỗi thành phần phải là tự chứa.Muốn là tự chứa
hoàn toàn thì một thành phần không nên dùng các thành phần ngoại lai.Tuy nhiên,
điều này lại mâu thuẫn với kinh nghiệm nói rằng các thành phần hiện có nên là
dùng lại được. Vậy là cần có một sự cân bằng giữa tính ưu việt của sự dùng lại các
thành phần (ở đây chủ yếu là các hàm) và sự mất mát tính thích ứng được của

24


chúng. Các thành của hệ thống phải có tính cố kết nhưng phải tương đối lỏng để dễ
thích nghi. Một trong cơ chế chính hỗ trợ để dễ có được tính thích nghi là kế thừa
thì cách tiếp cận hướng chức năng lại không hỗ trợ. Đó là cơ chế biểu diễn tính
tương tự của các thực thể, đơn giản hoá định nghĩa những khái niệm tương tự từ
những sự vật đã được định nghĩa trước trên cơ sở bổ sung hay thay đổi một số các
đặc trưng hay tính chất của chúng. Cơ chế này giúp chúng ta thực hiện được nguyên
lý tổng quát hoá và chi tiết hoá các thành phần của hệ thống phần mềm.
1.4.2 Cách tiếp cận hướng đối tượng
Để khắc phục được những vấn đề tồn tại nêu trên thì chúng ta cần phải nghiên
cứu phương pháp, mô hình và công cụ mới, thích hợp cho việc phát triển phần mềm
đáp ứng các yêu cầu của khách hàng. Mô hình hướng đối tượng ([1], [4], [9]) có thể
giúp chúng ta vượt được khủng hoảng trong công nghệ phần mềm và hy vọng sẽ
đưa ra được những sản phẩm phần mềm thương mại chất lượng cao: tin cậy, dễ mở
rộng, dễ thích nghi, cường tráng và phù hợp với yêu cầu của khách hàng. Cách tiếp
cận hướng đối tượng có những đặc trưng sau.

• Đặt trọng tâm vào dữ liệu (thực thể).
Khi khảo sát, phân tích một hệ thống chúng ta không tập trung vào các nhiệm
vụ như trước đây mà tìm hiểu xem nó gồm những thực thể nào. Thực thể hay còn
gọi là đối tượng, là những gì như người, vật, sự kiện, v.v. mà chúng ta đang quan
tâm, hay cần phải xử lý. Ví dụ, khi xây dựng “Hệ thống quản lý thư viện” thì trước
hết chúng ta tìm hiểu xem nó gồm những lớp đối tượng hoặc những khái niệm nào.

• Xem hệ thống như là tập các thực thể, các đối tượng.
Để hiểu rõ về hệ thống, chúng ta phân tách hệ thống thành các đơn thể đơn
giản hơn. Quá trình này được lặp lại cho đến khi thu được những đơn thể tương đối
đơn giản, dễ hiểu và thực hiện cài đặt chúng mà không làm tăng thêm độ phức tạp

khi liên kết chúng trong hệ thống. Xét “Hệ thống quản lý thư viện”, chúng ta có các
lớp đối tượng sau:

25