Tài liệu công nghệ phần mềm ppt

Câu 1: Trình bày nội dung vẽ sơ đồ, đánh giá ưu nhược điểm của các mô hình phát triền phần mềm sau
a. Thác nước
b. Bản mẫu nhanh
c. Xây dựng và hiệu chỉnh
d. Tăng dần
Trả lời
a. Mô hình thác nước
Trong mô hình này, quá trình phát triển phần mềm được coi như một dòng chảy trải qua các pha yêu
cầu, phân tích, thiết kế, cài đặt, tích hợp và bảo trì.
Có tính lặp của từng pha, nghĩa là nếu trong một pha người ta phát hiện ra điều gì đó sai sót hoặc
không phù hợp thì sẽ quay lại hiệu chỉnh ở pha trước. Hình 3.2 là sơ đồ biểu diễn mô hình thác đổ.
Hình 3.2. Mô hình thác đổ (waterfall model)
Mô hình thác đổ là mô hình cũ nhất và được sử dụng rộng rãi nhất trong công nghệ phần mềm. Tuy
nhiên cũng có nhiều ý kiến chỉ trích và cho rằng mô hình này có một số nhược điểm như sau:
• Các dự án trong thực tế hiếm khi tuân theo dòng chảy tuần tự mà mô hình đề nghị. Mặc dầu mô
hình cho phép lặp, nhưng điều đó chỉ làm gián tiếp. Kết quả là những thay đổi có thể gây ra lẫn
lộn khi nhóm phát triển làm việc.
• Khách hàng thường khó phát biểu mọi yêu cầu một cách tường minh ngay từ đầu. Mô hình tuần
tự tuyến tính đòi hỏi điều này và thường khó thích hợp với sự không chắc chắn tự nhiên tồn tại
vào lúc đầu của nhiều dự án. Khách hàng phải kiên nhẫn chờ đợi, vì bản làm việc được của
chương tình chỉ có được vào cuối của thời gian dự án. Một sai lầm ngớ ngẩn, nếu đến lúc có
chương trình làm việc mới phát hiện ra, có thể là một thảm họa.
• Với việc phân tích một số dự án hiện tại, Bradax thấy rằng bản chất tuyến tính của vòng đời cổ
điển dẫn tới "các trạng thái tắc nghẽn", nghĩa là có một số thành viên của nhóm phát triển phải
chờ đợi sự chuyển giao từ nhóm khác hoàn thành công việc ở pha trước. Trong thực tế, thời gian
chờ đợi có thể vượt quá thời gian sản xuất. Trạng thái nghẽn có xu hướng xẩy ra vào thời gian
đầu và cuối của quy trình phần mềm.
b. Bản mẫu nhanh
1
Phát triển
Bảo trì

Xác định yêu cầu
Phân tích
Thiết kế
Cài đặt
Tích hợp
Bảo trì
Thôi sử dụng
Thay đổi yêu cầu
Mô hình bản mẫu thực chất cũng là mô hình thác đổ, nhưng phần xác định yêu cầu được thay
bằng bản mẫu. Mô hình này có thể biểu diễn bởi sơ đồ sau:
Hình 3.3. Mô hình bản mẫu (rapid prototyping model)
Cũng như mô hình thác đổ, các pha từ bản mẫu đến thiết kế đều có kiểm tra (verify), các pha cài đặt và
tích hợp có kiểm thử (test).
Thông thường khách hàng đã xác định được một tập các mục tiêu tổng quát cho phần mềm, nhưng còn
chưa nhận diện được đầu vào, đầu ra, những cái cần xử lý. Trong các trường hợp khác người phát
triển có thể không chắc về tính hiệu quả của thuật toán, việc thích nghi hệ điều hành hay dạng màn
hình giao diện cần có. Trong trường hợp này và nhiều trường hợp khác, cách làm bản mẫu có thể đưa
ra cách tiếp cận tốt nhất.
Để làm bản mẫu, đầu tiên người ta thu thập yêu cầu khách hàng. Người phát triển và khách hàng cùng
ngồi lại với nhau để xác định các mục tiêu tổng thể cho phần mềm, xác định xem yêu cầu nào đã rõ
ràng, yêu cầu nào còn phải xác định thêm. Tiếp theo là việc "thiết kế nhanh". Thiết kế nhanh chỉ tập
trung vào việc biểu diễn các khía cạnh của phần mềm thấy được đối với người dùng, ví dụ màn hình
nhập dữ liệu, các chức năng tìm kiếm, truy xuất thông tin, các báo cáo. Người phát triển có thể kết hợp
để thử nghiệm một thuật toán. Tuy nhiên mục đích chính là thể hiện được các yêu cầu của khách hàng
trong phần mềm mà chưa để ý đến tính tối ưu, tốc độ, sự hợp lý Thiết kế nhanh dẫn tới việc xây dựng
một bản mẫu. Bản mẫu được giới thiệu với khách hàng và có thể để họ dùng thử và đánh giá, góp ý
kiến. Trên cơ sở ý kiến khách, hàng người phát triển làm mịn dần bản mẫu cho đến khi khách hàng
thấy vừa ý (chủ yếu là cái vào, cái ra, giao diện ). Căn cứ vào bản mẫu người phát triển cũng hiểu rõ
hơn yêu cầu khách hàng, những yêu cầu về cấu hình, về các thuật toán, cấu trúc dữ liệu, ngôn ngữ lập
trình phù hợp.

2
Phát triển
Bảo trì
Bản mẫu
Phân tích
Thiết kế
Cài đặt
Tích hợp
Bảo trì
Thôi sử dụng
Thay đổi yêu cầu
Lắng nghe
khách hàng
Xây dựng/hiệu chỉnh
bản mẫu
Khách hàng chạy
thử bản mẫu
Hình 3.4. Mô thức làm bản mẫu
c. Xây dựng và hiệu chỉnh
Trong mô hình này không có các pha phân tích thiết kế. Phần mềm được xây dựng như sau: người
phát triển sau khi trao đổi với khách hàng sẽ viết phiên bản đầu tiên. Tiếp theo, phần mềm được chạy
thử với sự quan sát của khách hàng và liên tục được hiệu chỉnh cho đến khi khách hàng vừa ý (tức là
đáp ứng được yêu cầu của khách hàng). Sau khi được khách hàng chấp nhận, phần mềm được đưa vào
sử dụng và bảo trì. Mô hình này có thể biểu diễn trong sơ đồ sau:
Hình 3.1. Mô hình xây dựng-và-hiệu chỉnh
Khi viết chương trình thì người phát triển cũng phải hình dung ra các chức năng của phần mềm, những
module phải có, những thuật toán sử dụng Nghĩa là phần nào đó họ cũng có phân tích thiết kế, nhưng
họ không biên soạn lại thành tài liệu mà thôi.
Sau khi viết phiên bản đầu tiên, người phát triển đã hiểu khá rõ yêu cầu của khách hàng, họ cũng hiểu
rõ các dòng lệnh vừa viết. Vì vậy khi khách hàng nêu yêu cầu hiệu chỉnh phần mềm thì họ biết ngay

cần phải hiệu chỉnh phần nào của chương trình. Công việc thường được thực hiện khá nhanh chóng và
phần mềm sớm được hoàn thành và đưa vào sử dụng.
Nhược điểm của mô hình thể hiện rõ trong giai đoạn bảo trì. Công việc bảo trì thường là sửa lỗi và cập
nhật. Nếu phần mềm vừa mới được đưa vào sử dụng và tác giả vẫn còn chịu trách nhiệm công việc này
thì không có vấn đề gì lắm. Tuy nhiên nếu phần mềm đã được sử dụng sau một thời gian dài, khiến cho
chính người viết chương trình cũng quên đi ý nghĩa các dòng lệnh; hoặc việc bảo trì lại do một người
khác thực hiện thì sẽ rất khó khăn. Nếu bạn thử đọc chương trình nguồn của một tác giả khác mà không
có tài liệu giải thích kèm theo thì bạn sẽ thấy rất khó hiểu.
Rõ ràng mô hình xây dựng-và-hiệu chỉnh chỉ thích nghi cho phần mềm nhỏ, một người viết và ít khả
năng phải sửa đổi trong quá trình sử dụng.
d. Tăng dần
Phần mềm được xây dựng từng bước, cũng như xây một ngôi nhà vậy. Nếu như khi xây dựng
ngôi nhà có lúc người ta phải phá đi xây lại một bức tường không vừa ý thì khi làm phần mềm chúng
ta cũng có thể sửa đổi thậm chí bỏ đi những module chương trình không phù hợp Một phần mềm ra
đời, được đưa vào sử dụng. Trong quá trình sử dụng ngoài việc phát hiện và sửa chữa sai sót, người ta
thấy cần nâng cấp chất lượng bằng cách cải tiến một vài thuật toán, thêm một số chức năng.
Trong mô hình tăng dần, người ta xem phần mềm bao gồm nhiều thành phần (build) tương đối độc lập
nhau. Với hệ điều hành chẳng hạn, đó là thành phần scheduler, thành phần file management system,
Mỗi thành phần như vậy được coi như một phần mềm nhỏ, được thiết kế, lập trình, kiểm thử và đưa
cho khách hàng sử dụng theo mô hình thác đổ rồi kết hợp dần thành phần mềm hoàn chỉnh thỏa mãn tất
cả các yêu cầu của khách hàng. Ban đầu người ta chưa chú ý đến toàn bộ các yêu cầu của phần mềm
3
Xây dựng phiên
bản đầu tiên
Hiệu chỉnh cho đến khi
khách hàng chấp nhận
Sử dụng và
bảo trì
Thôi sử dụng
Phát triển

Bảo trì
mà chỉ chú ý đến những nét đặc trưng nhất và xây dựng phiên bản đầu tiên của phần mềm bao gồm
các đặc trưng này rồi đưa cho khách hàng sử dụng. Chương trình được hiệu chỉnh theo ý kiến phản hồi
của khách hàng. Tiếp theo người ta lại xây dựng phần mềm thứ hai thỏa mãn các đặc trưng quan
trọng thứ hai và lại đưa cho khách hàng sử dụng và có ý kiến. Phần mềm thứ hai này sau khi hiệu
chỉnh lại được tích hợp vào phần mềm đầu tiên thành một phần mềm lớn hơn. Phần mềm tích hợp này
lại được kiểm thử để bảo đảm việc ghép nối thành công và chương trình chạy tốt. Cứ như vậy, thay vì
xây dựng phần mềm hoàn chỉnh, người ta xây dựng các phần mềm con rồi tích hợp dần cho tới khi
đạt được sản phẩm mong muốn. Sơ đồ sau mô tả mô hình tăng dần.
Hình 3.5. Mô hình tăng dần (incremental model)
Nhận xét mô hình tăng dần
Với mô hình thác đổ hoặc bản mẫu, sản phẩm được chuyển giao cho khách hàng chính là phiên bản
hoàn chỉnh thỏa mãn tất cả các yêu cầu của khách hàng và có thể sử dụng ngay. Thời gian hoàn thành
phần mềm được quy định trong hợp đồng và có thể sớm hoặc muộn hơn. Với mô hình tăng dần thì
phần mềm được chia ra nhiều phần (thường là từ 5 đến 25 phần). Phần đầu tiên chứa đựng những đặc
trưng quan trọng nhất được nhanh chóng xây dựng và chuyển giao cho khách hàng sử dụng. Thời gian
hoàn thành phần đầu tiên này thường rất ngắn so với thời gian xây dựng toàn bộ phần mềm hoàn chỉnh.
Như vậy khách hàng được sử dụng sản phẩm trong thời gian ngắn nhất và họ có thể được hưởng lợi từ
việc sử dụng phần mềm. Khi mỗi phần sau được hoàn thành và được tích hợp thì họ được sử dụng
ngay. Như vậy họ được làm quen từng bước với sản phẩm và sẽ ít bỡ ngỡ khi sản phẩm chứa đựng
những công nghệ mới. Nhờ theo sát từng bước phát triển của phần mềm mà khách hàng có thể có
những ý kiến xác đáng, giúp cho nhà phát triển đi đúng hướng và sản phẩm cuối cùng sẽ thỏa mãn
được các yêu cầu đặt ra, thậm chí qua việc sử dụng một số phần đầu, khách hàng nhận thấy rằng không
nên phát triển tiếp vì sẽ không mang lại lợi ích kinh tế.
Khó khăn trong việc sử dụng mô hình tăng dần chính là sự tích hợp phần mới phát triển với phần
chương trình đã có. Thiết kế của mô hình này do vậy phải có tính mở và tính mềm dẻo để thích nghi với
việc mở rộng dần. Ta có thể nhận thấy rằng, trong mô hình tăng dần không có sự khác biệt giữa sự phát
triển phần mềm và bảo trì cập nhật (nâng cao). Nếu vận dụng không hợp lý, mô hình này có thể suy
thoái thành mô hình xây dựng-và-hiệu chỉnh. Sự điều khiển toàn bộ quy trình phát triển phần mềm có
thể bị mất và sản phẩm nhận được thay vì có tính mở lại là nỗi kinh hoàng cho những người bảo trì. Để

tránh được điều này, người phát triển ngay từ đầu phải có cách nhìn toàn cục về sản phẩm, phải đưa
4
Phát triển
Bảo trì
Xác định yêu cầu
Phân tích
Thiết kế kiến trúc
Với mỗi build thực hiện:
Thiết kế chi tiết, lập trình, tích
hợp, kiểm thử rồi chuyển giao
cho khách hàng
Bảo trì
Thôi sử dụng
ra thiết kế tổng thể của sản phẩm và sự phân chia các thành phần để phát triển sau này cũng phải trên
cơ sở thiết kế toàn cục đó. Như sơ đồ 3.5. chỉ ra, các pha yêu cầu, đặc tả và thiết kế kiến trúc phải
được thực hiện trước khi các thành phần nhỏ hơn được bắt đầu xây dựng. Nếu không có những nhà
chuyên môn trình độ cao thì sản phẩm phát triển theo mô hình này có thể trở thành sản phẩm kém chất
lượng.
Câu 2: Phân biệt các yêu cầu chức năng và phi chức năng của phần mềm, nêu ví dụ minh họa
Trả lời
Yêu cầu chức năng thường gắn với chức năng tương ứng của phần mềm cần xây dựng và thể hiện dưới
dạng các mục chọn của thực đơn, ví dụ như: "Phần mềm cung cấp chức năng tìm kiếm hàng hóa theo
tên hàng và ngày bán". Đặc tả phi chức năng dùng để chỉ rõ tính chất nào đó của phần mềm cần xây
dựng, ví dụ tính tin cậy và bảo trì được; hoặc liên quan đến môi trường mà phần mềm được sử dụng, ví
dụ: tất cả các mã khách hàng được nhập trực tiếp từ bàn phím và được lưu trong một tệp bảng dữ liệu".
Tóm lại yêu cầu chức năng là nói đến một công việc cụ thể, thường thể hiện bằng các mục chọn trong
chương trình; còn yêu cầu phi chức năng thì nói về các tính chất của phần mềm, các tính chất này
không thể thể hiện được bằng một việc cụ thể. Thí dụ từ câu "yêu cầu phần mềm phải có giao diện đẹp,
thân thiện với người sử dụng" ta không thể nói được cụ thể là phải làm gì.
Câu 3: Trình bày các phương pháp kiểm thử phần mềm

Loại được đóng gói bán ra thị trường:
Kiểm thử toàn bộ sản phẩm (product testing). Mục đích của việc kiểm thử này là bảo đảm rằng sản
phẩm không có lỗi.
Khi việc kiểm thử hoàn tất thì sản phẩm được chuyển qua giai đoạn kiểm thử alpha và beta. Nghĩa là
phiên bản ban đầu được đưa cho một số khách hàng tương lai để họ sử dụng, Những thông tin phản hồi
từ khách hàng được nhóm SQA xem xét và sản phẩm lại được hiệu chỉnh bởi nhóm phát triển nếu có
lỗi được phát hiện.
Loại làm theo hợp đồng cho một khách hàng:
Đối với phần mềm đặt hàng (custom software) thì cách thức kiểm thử toàn bộ sản phẩm có khác chút ít.
Nhóm SQA tiến hành một số kiểm thử để bảo đảm rằng sản phẩm có thể vượt qua được giai đoạn kiểm
thử chấp nhận (acceptance test), tức là giai đoạn mà chương trình được cài đặt trên máy khách hàng,
chạy với cấu hình và số liệu thực và được kiểm tra bởi khách hàng. Kiểm thử chấp nhận chính là rào
cản cuối cùng mà nhóm phát triển phải vượt qua.
Việc kiểm thử trước khi chuyển cho khách hàng kiểm tra là vô cùng quan trọng, do đó phải được thực
hiện một cách thân trọng qua các bước như sau:
1. Thực hiện phép thử hộp đen cho toàn bộ sản phẩm. Trong quá trình tích hợp các module, ta mới
chỉ kiểm thử xem từng module có thỏa mãn đặc tả không và phần mềm sau từng bước lắp ghép có
hoạt động tốt không. Sản phẩm sau khi được tạo ra phải được kiểm thử một cách toàn diện. Kiểm
thử hộp đen có nghĩa là kiểm tra xem chương trình chạy tốt không, tính toán cho kết quả chính xác
không, nghĩa là ta chỉ quan tâm đến phần bên ngoài của phần mềm. Phần cấu trúc bên trong bị hộp
đen (black-box) che khuất. (Hộp đen ở đây được dùng với ý nghĩa là không chú ý đến bên trong).
2. Cần kiểm thử tính ổn định (robustness) của sản phẩm một cách toàn cục. Tính ổn định của các
module và từng phần của phần mềm đã được kiểm thử trong quá trình tích hợp. Khi quá trình tích
hợp kết thúc thì phải kiểm thử tính ổn định của phần mềm một cách toàn cục. Cần có các trường hợp
mẫu khác nhau để thử tính ổn định. Đặc biệt chú ý các kiểm thử cực điểm (stress testing) , tức là
kiểm thử được thực hiện khi phần mềm hoạt động ở mức tối đa, ví dụ tất cả các màn hình làm việc
(terminal) đều được sử dụng, hay như với phần mềm điều khiển máy rút tiền thì tất cả các máy rút
tiền đều được khách hàng sử dụng Hay kiểm thử dung lượng (volume testing), ví dụ phần mềm có
khả năng xử lý tệp dữ liệu đầu vào lớn không
5

3. Nhóm SQA cần kiểm tra xem phần mềm đã thỏa mãn tất cả các ràng buộc nêu ra trong bản đặc tả
hay chưa. Ví dụ, nếu bản đặc tả nói rằng khi chương trình đang làm việc ở mức tối đa (working
under full load) thì 95% các yêu cầu truy xuất thông tin được trả lời trong vòng 3 giây chẳng hạn,
thì nhóm SQA phải kiểm thử xem có đúng như vậy không. Ngoài ra, cần kiểm tra những ràng buộc
về khả năng lưu trữ dữ liệu và tính bảo mật (storage constraints and security constraints).
4. Nhóm SQA cần xem xét lại tất cả tài liệu và chương trình cần chuyển giao cho khách hàng, có
đối chiếu với bản kế hoạch quản lý dự án phần mềm. Kiểm tra các tài liệu có phù hợp với phần
mềm không. Ví dụ xem lại tài liệu sử dụng và thử dùng nó để thao tác phần mềm xem phần mềm
hoạt động đúng như tài liệu mô tả không.
Câu 4: Trình bày các phương pháp cài đặt và tích hợp phần mềm từ trên xuống và từ dưới lên.
Cài đặt và tích hợp từ trên xuống (top-down)
Trong phương pháp cài đặt và tích hợp theo kiểu trên xuống (top-down implementation and
integration), nếu module A có lời gọi đến module B thì A được cài đặt và kiểm thử trước B. Để
kiểm thử A thì B cần được cài đặt dưới dạng stub. Sau khi A được kiểm thử thì cài đặt stub của B
được mở rộng thành cài đặt thực sự
Cài đặt và tích hợp từ dưới lên (bottom-up)
Phương pháp cài đặt và tích hợp theo kiểu dưới lên (bottom-up) được thực hiện ngược lại với phương
pháp trên xuống. Đầu tiên các module ở mức dưới cùng (hay đôi khi còn gọi là mức cao nhất nếu nói
về chiều cao của cây) được cài đặt và kiểm thử. Sau đó là các module ở mức phía trên được cài đặt và
kiểm thử cùng với các module ở mức dưới. Cứ như vậy cho đến khi các module ở mức trên cùng được
cài đặt và kiểm thử thì quá trình hoàn tất.
Có thể thấy rằng phương pháp bottom-up có ưu điểm hơn phương pháp top-down ở chỗ là không phải
tạo cài đặt dạng stub (các module ở tầng dưới cùng thường phải thử với các driver). Tuy nhiên nó cũng
có một nhược điểm khá lớn là: nếu lỗi phát hiện ra muộn, tức là ở các mức ở gần gốc của cây chẳng
hạn, lúc đó toàn bộ phần dưới của cây phải xem xét lại.
Câu 5: Trình bày các công việc chính khi bảo trì một phần mềm
Sau khi sản phẩm trải qua kiểm thử chấp nhận và thành công, phần mềm sẽ được huyển giao cho khách
hàng. Thực ra, khi thực hiện kiểm thử chấp nhận thì phần mềm cũng được cài đặt trên máy tính của
khách hàng, nhưng chỉ với mục đích kiểm thử. Trong quá trình này nếu phát hiện lỗi thì nhóm phát
triển lại hiệu chỉnh phần mềm. Còn sự chuyển giao sau khi hoàn tất giai đoạn kiểm thử là sự chuyển

giao chính thức theo hợp đồng. Sau đó phần mềm sẽ được khách hàng sử dụng vào công việc mà họ đặt
ra ban đầu khi đặt hàng xây dựng phần mềm. Nhiều người nghĩ rằng vai trò của nhóm phát triển đến
đây kết thúc, vì phần mềm đã hoàn tất. Tuy nhiên, mọi phần mềm có ích hầu như chắc chắn chuyển qua
một giai đoạn hiệu chỉnh mà người ta gọi là pha bảo trì. Công việc bảo trì được phân làm hai loại: bảo
trì sửa lỗi (software repair), tức là sửa các lỗi phát sinh mà trong giai đoạn kiểm thử chưa phát hiện ra.
Cho dù việc kiểm thử có tiến hành cẩn thận và chi tiết đến đâu thì vẫn không thể khẳng định là phần
mềm đã làm việc hoàn hảo. Vì con người dù rất thông minh cũng không thể hình dung trước được mọi
tình huống. Loại bảo trì thứ hai là bảo trì cập nhật (software update). Bảo trì cập nhật lại bao gồm bảo
trì hoàn thiện (perfective maintenance) và bảo trì thích nghi (adaptive maintenance).
Bởi vì ngoài các mã nguồn còn các tài liệu khác như hướng dẫn sử dụng, tài liệu phân tích thiết
kế, nên mọi sự thay đổi hiệu chỉnh trong các phần này đều được gọi là bảo trì.
Câu 6: So sánh hai phương pháp phát triển phần mềm hướng đối tượng và hướng chức năng.
Phương pháp hướng cấu trúc
Đặc trưng của phương pháp hướng cấu trúc là phân chia chương trình chính thành nhiều chương
6
trình con, mỗi chương trình con nhằm đến thực hiện một công việc xác định.
Trong phương pháp hướng cấu trúc, phần mềm được thiết kế dựa trên một trong hai hướng :
hướng dữ liệu và hướng hành động.
Cách tiếp cận hướng dữ liệu xây dựng phần mềm dựa trên việc phân rã phần mềm theo các chức
năng cần đáp ứng và dữ liệu cho các chức năng đó. Cách tiếp cận hướng dữ liệu sẽ giúp cho
những người phát triển hệ thống dễ dàng xây dựng ngân hàng dữ liệu.
Cách tiếp cận hướng hành động lại tập trung phân tích hệ phần mềm dựa trên các hoạt động thực
thi các chức năng của phần mềm đó.
Cách thức thực hiện của phương pháp hướng cấu trúc là phương pháp thiết kế từ trên xuống
(top-down). Phương pháp này tiến hành phân rã bài toán thành các bài toán nhỏ hơn, rồi tiếp tục
phân rã các bài toán con cho đến khi nhận được các bài toán có thể cài đặt được ngay sử dụng
các hàm của ngôn ngữ lập trình hướng cấu trúc.
Phương pháp hướng cấu trúc có ưu điểm là tư duy phân tích thiết kế rõ ràng, chương trình sáng
sủa dễ hiểu. Tuy nhiên, phương pháp này có một số nhược điểm sau:
Không hỗ trợ việc sử dụng lại. Các chương trình hướng cấu trúc phụ thuộc chặt chẽ vào cấu trúc

dữ liệu và bài toán cụ thể, do đó không thể dùng lại một modul nào đó trong phần mềm này cho
phần mềm mới với các yêu cầu về dữ liệu khác.
Không phù hợp cho phát triển các phần mềm lớn. Nếu hệ thống thông tin lớn, việc phân ra thành
các bài toán con cũng như phân các bài toán con thành các modul và quản lý mối quan hệ giữa
các modul đó sẽ là không phải là dễ dàng và dễ gây ra các lỗi trong phân tích và thiết kế hệ
thống, cũng như khó kiểm thử và bảo trì.
Phương pháp hướng đối tượng
Khác với phương pháp hướng cấu trúc chỉ tập trung hoặc vào dữ liệu hoặc vào hành động,
phương pháp hướng đối tượng tập trung vào cả hai khía cạnh của hệ thống là dữ liệu và hành
động.
Cách tiếp cận hướng đối tượng là một lối tư duy theo cách ánh xạ các thành phần trong bài toán
vào các đối tượng ngoài đời thực. Với cách tiếp cận này, một hệ thống được chia tương ứng
thành các thành phần nhỏ gọi là các đối tượng, mỗi đối tượng bao gồm đầy đủ cả dữ liệu và
hành động liên quan đến đối tượng đó.
Các đối tượng trong một hệ thống tương đối độc lập với nhau và phần mềm sẽ được xây dựng
bằng cách kết hợp các đối tượng đó lại với nhau thông qua các mối quan hệ và tương tác giữa
7
chúng.
Các nguyên tắc cơ bản của phương pháp hướng đối tượng bao gồm :
• Trừu tượng hóa (abstraction): trong phương pháp hướng đối tượng, các thực thể phần mềm
được mô hình hóa dưới dạng các đối tượng. Các đối tượng này được trừu tượng hóa ở mức cao
hơn dựa trên thuộc tính và phương thức mô tả đối tượng để tạo thành các lớp. Các lớp cũng sẽ
được trừu tượng hóa ở mức cao hơn nữa để tạo thành một sơ đồ các lớp được kế thừa lẫn nhau.
Trong phương pháp hướng đối tượng có thể tồn tại những lớp không có đối tượng tương ứng,
gọi là lớp trừu tượng. Như vậy, nguyên tắc cơ bản để xây dựng các khái niệm trong hướng đối
tượng là sự trừu tượng hóa theo các mức độ khác nhau.
• Tính đóng gói (encapsulation) và ẩn dấu thông tin: các đối tượng có thể có những phương
thức hoặc thuộc tính riêng (kiểu private) mà các đối tượng khác không thể sử dụng được. Dựa
trên nguyên tắc ẩn giấu thông tin này, cài đặt của các đối tượng sẽ hoàn toàn độc lập với các đối
tượng khác, các lớp độc lập với nhau và cao hơn nữa là cài đặt của hệ thống hoàn toàn độc lập

với người sử dụng cũng như các hệ thống khác sử dụng kết quả của nó.
• Tính modul hóa (modularity): các bài toán sẽ được phân chia thành những vấn đề nhỏ hơn,
đơn giản và quản lý được.
• Tính phân cấp (hierarchy): cấu trúc chung của một hệ thống hướng đối tượng là dạng phân
cấp theo các mức độ trừu tượng từ cao đến thấp.
Ưu điểm nổi bật của phương pháp hướng đối tượng là đã giải quyết được các vấn đề nảy sinh
với phương pháp hướng cấu trúc:
• Hỗ trợ sử dụng lại mã nguồn : Chương trình lập trình theo phương pháp hướng đối tượng
thường được chia thành các gói là các nhóm của các lớp đối tượng khác nhau. Các gói này hoạt
động tương đối độc lập và hoàn toàn có thể sử dụng lại trong các hệ thống thông tin tương tự.
• Phù hợp với các hệ thống lớn: Phương pháp hướng đối tượng không chia bài toán thành các
bài toán nhỏ mà tập trung vào việc xác định các đối tượng, dữ liệu và hành động gắn với đối
tượng và mối quan hệ giữa các đối tượng. Các đối tượng hoạt động độc lập và chỉ thực hiện
hành động khi nhận được yêu cầu từ các đối tượng khác. Vì vậy, phương pháp này hỗ trợ phân
tích, thiết kế và quản lý một hệ thống lớn, có thể mô tả các hoạt động nghiệp vụ phức tạp bởi
quá trình phân tích thiết kế không phụ thuộc vào số biến dữ liệu hay số lượng thao tác cần thực
hiện mà chỉ quan tâm đến các đối tượng tồn tại trong hệ thống đó.
8